home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / rfc / rfc987 < prev    next >
Encoding:
Text File  |  1991-04-20  |  120.7 KB  |  3,933 lines
  1.  
  2.  
  3. UCL Technical Report 120
  4. Mailgroup Note 19
  5.  
  6. Network Working Group                                         S.E. Kille
  7. Request for Comments: 987                      University College London
  8.                                                                June 1986
  9.  
  10.                    Mapping between X.400 and RFC 822
  11.  
  12.  
  13. Status of This Memo
  14.  
  15.    This RFC suggests a proposed protocol for the ARPA-Internet
  16.    community, and requests discussion and suggestions for improvements.
  17.    Distribution of this memo is unlimited.
  18.  
  19.    This document describes a set of mappings which will enable
  20.    interworking between systems operating the CCITT X.400 (1984) series
  21.    of protocols [CCITT84a], and systems using the RFC 822 mail protocol
  22.    [Crocker82a], or protocols derived from RFC 822.  The approach aims
  23.    to maximise the services offered across the boundary, whilst not
  24.    requiring unduly complex mappings.  The mappings should not require
  25.    any changes to end systems.
  26.  
  27.    This specification should be used when this mapping is performed on
  28.    the ARPA-Internet or in the UK Academic Community.  This
  29.    specification may be modified in the light of implementation
  30.    experience, but no substantial changes are expected.
  31.  
  32.  
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56. Kille                                                           [Page 1]
  57.  
  58.  
  59.  
  60. RFC 987                                                        June 1986
  61. Mapping between X.400 and RFC 822
  62.  
  63.  
  64. Chapter 1 -- Overview
  65.  
  66.    1.1.  X.400
  67.  
  68.       The X.400 series protocols have been defined by CCITT to provide
  69.       an Interpersonal Messaging Service (IPMS), making use of a store
  70.       and forward Message Transfer Service.  It is expected that this
  71.       standard will be implemented very widely.  As well as the base
  72.       standard (X.400), work is underway on various functional standards
  73.       of profiles which specify how X.400 will be used in various
  74.       communities.  Many of the major functional standards (e.g. from
  75.       CEPT, CEN/CENELEC, and NBS) are likely to be similar.  Some of the
  76.       decisions in this document are in the light of this work.  No
  77.       reference is given, as these documents are not currently stable.
  78.  
  79.    1.2.  RFC 822
  80.  
  81.       RFC 822 evolved as a messaging standard on the DARPA (the US
  82.       Defense Advanced Research Projects Agency) Internet.  It is
  83.       currently used on the ARPA-Internet in conjunction with two other
  84.       standards: RFC 821, also known as Simple Mail Transfer Protocol
  85.       (SMTP) [Postel82a], and RFC 920 which is a specification for a
  86.       domain name system and a distributed name service [Postel84a].
  87.       RFC 822, or protocols derived from RFC 822 are used in a number of
  88.       other networks.  In particular:
  89.  
  90.          UUCP Networks
  91.  
  92.             UUCP is the UNIX to UNIX CoPy protocol <0>, which is usually
  93.             used over dialup telephone networks to provide a simple
  94.             message transfer mechanism.  There are some extensions to
  95.             RFC 822, particularly in the addressing.  They are likely to
  96.             use domains which conform to RFC 920, but not the
  97.             corresponding domain nameservers [Horton86a].
  98.  
  99.          CSNET
  100.  
  101.             Some portions of CSNET will follow the ARPA-Internet
  102.             protocols. The dialup portion of CSNET uses the Phonenet
  103.             protocols as a replacement for RFC 821.  This portion is
  104.             likely to use domains which conform to RFC 920, but not the
  105.             corresponding domain nameservers.
  106.  
  107.          BITNET
  108.  
  109.             Some parts of BITNET use RFC 822 related protocols, with
  110.             EBCDIC encoding.
  111.  
  112.  
  113. Kille                                                           [Page 2]
  114.  
  115.  
  116.  
  117. RFC 987                                                        June 1986
  118. Mapping between X.400 and RFC 822
  119.  
  120.  
  121.          JNT Mail Networks
  122.  
  123.             A number of X.25 networks, particularly those associated
  124.             with the UK Academic Community, use the JNT (Joint Network
  125.             Team) Mail Protocol, also known as Greybook [Kille84a].
  126.             This is used with domains and name service specified by the
  127.             JNT NRS (Name Registration Scheme) [Larmouth83a].
  128.  
  129.       The mappings specified here are appropriate for all of these
  130.       networks.
  131.  
  132.    1.3.  The Need for Conversion
  133.  
  134.       There is a large community using RFC 822 based protocols for mail
  135.       services, who will wish to communicate with X.400 systems.  This
  136.       will be a requirement, even in cases where communities intend to
  137.       make a transition to use of X.400, where conversion will be needed
  138.       to ensure a smooth service transition.  It is expected that there
  139.       will be more than one gateway <1>, and this specification will
  140.       enable them to behave in a consistent manner.  These gateways are
  141.       sometimes called mail relays.  Consistency between gateways is
  142.       desirable to provide:
  143.  
  144.          1.   Consistent service to users.
  145.  
  146.          2.   The best service in cases where a message passes through
  147.               multiple gateways.
  148.  
  149.    1.4.  General Approach
  150.  
  151.       There are a number of basic principles underlying the details of
  152.       the specification.
  153.  
  154.          1.   The specification should be pragmatic.  There should not
  155.               be a requirement for complex mappings for 'Academic'
  156.               reasons.  Complex mappings should not be required to
  157.               support trivial additional functionality.
  158.  
  159.          2.   Subject to 1), functionality across a gateway should be as
  160.               high as possible.
  161.  
  162.          3.   It is always a bad idea to lose information as a result of
  163.               any transformation.  Hence, it is a bad idea for a gateway
  164.               to discard information in the objects it processes.  This
  165.               includes requested services which cannot be fully mapped.
  166.  
  167.          4.   All mail gateways actually operate at exactly one level
  168.  
  169.  
  170. Kille                                                           [Page 3]
  171.  
  172.  
  173.  
  174. RFC 987                                                        June 1986
  175. Mapping between X.400 and RFC 822
  176.  
  177.  
  178.               above the layer on which they conceptually operate.  This
  179.               implies that the gateway must not only be cognisant of the
  180.               semantics of objects at the gateway level, but also be
  181.               cognisant of higher level semantics.  If meaningful
  182.               transformation of the objects that the gateway operates on
  183.               is to occur, then the gateway needs to understand more
  184.               than the objects themselves.
  185.  
  186.    1.5.  Gatewaying Model
  187.  
  188.       1.5.1.  X.400
  189.  
  190.          The CCITT X.400 series recommendations specify a number of
  191.          services and protocols.  The services are specified in X.400.
  192.          Two of these services are fundamental to this document:
  193.  
  194.             1.   The Message Transfer Service, which can be provided by
  195.                  either the P1 or P3 protocols, which are  specified in
  196.                  X.411 [CCITT84b]. This document talks in terms of P1,
  197.                  but the mappings are equally applicable to P3.
  198.  
  199.             2.   The Interpersonal Messaging Service (IPMS), which is
  200.                  provided by the P2 protocol specified in X.420
  201.                  [CCITT84c].
  202.  
  203.          This document considers only IPMS, and not of any other usage
  204.          of the Message Transfer Service.  This is reasonable, as
  205.          RFC 822, broadly speaking, provides a service corresponding to
  206.          IPMS, and no services other than IPMS have been defined over
  207.          the Message Transfer Service. As none of the RTS (Reliable
  208.          Transfer Service) service elements is available to the IPMS
  209.          user, this level and lower levels are of no concern in this
  210.          gatewaying specification.  Note that in this memo "IP" means
  211.          "InterPersonal" (not Internet Protocol).
  212.  
  213.          The Message Transfer Service defines an end-to-end service over
  214.          a series of Message Transfer Agents (MTA).  It also defines a
  215.          protocol, P1, which is used between a pair of MTAs.  This
  216.          protocol is simply a file format (Message Protocol Data Unit,
  217.          or MPDU), transferred between two MTAs using the RTS.  There
  218.          are three types of MPDU:
  219.  
  220.             User MPDU
  221.  
  222.                This contains envelope information, and uninterpreted
  223.                contents. The envelope includes an ID, an originator, a
  224.  
  225.  
  226.  
  227. Kille                                                           [Page 4]
  228.  
  229.  
  230.  
  231. RFC 987                                                        June 1986
  232. Mapping between X.400 and RFC 822
  233.  
  234.  
  235.                list of recipients, and trace information.  It is used to
  236.                carry data for higher level services.
  237.  
  238.             Probe
  239.  
  240.                This contains only envelope information.  It is used to
  241.                determine whether a User UMPDU could be delivered to a
  242.                given O/R (originator/recipient) name.
  243.  
  244.             Delivery Report
  245.  
  246.                This contains envelope information, and specified
  247.                contents.  It is used to indicate delivery success or
  248.                failure of a User or Probe MPDU over the Message Transfer
  249.                Service.
  250.  
  251.          IPMS (P2) specifies two content types for the P1 User MPDU
  252.          (User Agent Protocol Data Units or UAPDU):
  253.  
  254.             Interpersonal Message (IM-UAPDU)
  255.  
  256.                This has two components: a heading, and a body.  The body
  257.                is structured as a sequence of body parts, which may be
  258.                basic components (e.g.IA5 text, or G3 fax), or IP
  259.                Messages.  The header contains end to end user
  260.                information, such as subject, primary recipients (To:),
  261.                and priority.  The validity of these fields is not
  262.                guaranteed by the Message Transfer Service.  This
  263.                provides the basic IPMS.
  264.  
  265.             Status Report (SR-UAPDU)
  266.  
  267.                This UAPDU has defined contents.  It is used to indicate
  268.                that a message has been received by a User Agent.  It
  269.                does not have to be implemented.
  270.  
  271.       1.5.2.  RFC 822
  272.  
  273.          RFC 822 is based on the assumption that there is an underlying
  274.          service, which is here called the 822-P1 service.  The 822-P1
  275.          service provides three basic functions:
  276.  
  277.             1.   Identification of a list of recipients.
  278.  
  279.             2.   Identification of an error return address.
  280.  
  281.             3.   Transfer of an RFC 822 message.
  282.  
  283.  
  284. Kille                                                           [Page 5]
  285.  
  286.  
  287.  
  288. RFC 987                                                        June 1986
  289. Mapping between X.400 and RFC 822
  290.  
  291.  
  292.          It is possible to achieve 2) within the RFC 822 header.  Some
  293.          822-P1 protocols, in particular SMTP, can provide additional
  294.          functionality, but as these are neither mandatory in SMTP, nor
  295.          available in other 822-P1 protocols, they are not considered
  296.          here.  Details of aspects specific to a number of 822-P1
  297.          protocols are given in appendices B to E.  An RFC 822 message
  298.          consists of a header, and content which is uninterpreted ASCII
  299.          text.  The header is divided into fields, which are the
  300.          protocol elements.  Most of these fields are analogous to P2
  301.          header elements, although some are analogous to P1 envelope
  302.          elements.
  303.  
  304.       1.5.3.  The Gateway
  305.  
  306.          Given this functional description of the two protocols, the
  307.          functional nature of a gateway can now be considered.  It would
  308.          be elegant to consider the 822-P1 service mapping onto P1 and
  309.          RFC 822 mapping onto P2, but reality just does not fit.
  310.          Therefore one must consider that P1 or P1 + P2 on one side are
  311.          mapped into RFC 822 + 822-P1 on the other in a slightly tangled
  312.          manner.  The details of the tangle will be made clear in
  313.          chapter 5.  The following basic mappings are thus proposed.
  314.          When going from RFC 822 to X.400, an RFC 822 message and the
  315.          associated 822-P1 information is always mapped into an IM-UAPDU
  316.          and the associated P1 envelope.  Going from X.400 to RFC 822,
  317.          an RFC 822 message and the associated 822-P1 information may be
  318.          derived from:
  319.  
  320.             1.   A Delivery Report MPDU
  321.  
  322.             2.   An SR-UAPDU and the associated P1 envelope.
  323.  
  324.             3.   An IM-UAPDU and the associated P1 envelope.
  325.  
  326.          Probe MPDUs must be processed by the gateway - this is
  327.          discussed in chapter 5.  Any other User MPDUs are not mapped by
  328.          the gateway, and should be rejected at the gateway.
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338.  
  339.  
  340.  
  341. Kille                                                           [Page 6]
  342.  
  343.  
  344.  
  345. RFC 987                                                        June 1986
  346. Mapping between X.400 and RFC 822
  347.  
  348.  
  349.    1.6.  Document Structure
  350.  
  351.       This document has five chapters:
  352.  
  353.          1.   Overview - this document.
  354.  
  355.          2.   Service Elements - This describes the (end user) services
  356.               mapped by a gateway.
  357.  
  358.          3.   Basic mappings - This describes some basic notation used
  359.               in chapters 3-5, the mappings between character sets, and
  360.               some fundamental protocol elements.
  361.  
  362.          4.   Addressing - This considers the mapping between X.400 O/R
  363.               names and RFC 822 addresses, which is a fundamental
  364.               gateway component.
  365.  
  366.          5.   Protocol Elements - This describes the details of all
  367.               other mappings.
  368.  
  369.       There are also six appendices:
  370.  
  371.          A.   Quoted String Encodings.
  372.  
  373.          B.   Mappings Specific to JNT Mail.
  374.  
  375.          C.   Mappings Specific to Internet Mail.
  376.  
  377.          D.   Mappings Specific to Phonenet Mail.
  378.  
  379.          E.   Mappings Specific to UUCP Mail.
  380.  
  381.          F.   Format of Address Tables.
  382.  
  383.    1.7.  Acknowledgements
  384.  
  385.       This document is eclectic, and credit should be given:
  386.  
  387.          -    Study of the EAN X.400 system code which performs this
  388.               function [Neufeld85a].  Some detailed clarification was
  389.               made by the DFN report on EAN [Bonacker85a].
  390.  
  391.          -    An unpublished ICL report, which considered a subset of
  392.               the problem [ICL84a].
  393.  
  394.          -    A document by Marshall Rose [Rose85a].
  395.  
  396.  
  397.  
  398. Kille                                                           [Page 7]
  399.  
  400.  
  401.  
  402. RFC 987                                                        June 1986
  403. Mapping between X.400 and RFC 822
  404.  
  405.  
  406.          -    A document by Mark Horton [Horton85a].  The string
  407.               encodings of chapter 3 were derived directly from this
  408.               work, as is much of chapter 4.
  409.  
  410.          -    Discussion on a number of electronic mailing lists.
  411.  
  412.          -    Meetings in the UK and the US.
  413.  
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450.  
  451.  
  452.  
  453.  
  454.  
  455. Kille                                                           [Page 8]
  456.  
  457.  
  458.  
  459. RFC 987                                                        June 1986
  460. Mapping between X.400 and RFC 822
  461.  
  462.  
  463. Chapter 2 -- Service Elements
  464.  
  465.    RFC 822 and X.400 provide a number of services to the end user.  This
  466.    document describes the extent to which each service can be supported
  467.    across an X.400 <-> RFC 822 gateway.  The cases considered are single
  468.    transfers across such a gateway, although the problems of multiple
  469.    crossings are noted where appropriate.
  470.  
  471.    When a service element is described as supported, this means that
  472.    when this service element is specified by a message originator for a
  473.    recipient behind a gateway, that it is mapped by the gateway to
  474.    provide the service implied by the element.  For example, if an
  475.    RFC 822 originator specifies a Subject: field, this is considered to
  476.    be supported, as an X.400 recipient will get a subject indication.
  477.    Support implies:
  478.  
  479.       -    Semantic correspondence.
  480.  
  481.       -    No loss of information.
  482.  
  483.       -    Any actions required by the service element.
  484.  
  485.    For some services, the corresponding protocol elements map well, and
  486.    so the service can be fully provided.  In other cases, the service
  487.    cannot be provided, as there is a complete mismatch.  In the
  488.    remaining cases, the service can be partially fulfilled.  The level
  489.    of partial support is summarised.
  490.  
  491.       NOTE:  It should be clear that support of service elements on
  492.       reception is not a gatewaying issue.  It is assumed that all
  493.       outbound messages are fully conforming to the appropriate
  494.       standards.
  495.  
  496.    2.1.  RFC 822
  497.  
  498.       RFC 822 does not explicitly define service elements, as distinct
  499.       from protocol elements.  However, all of the RFC 822 header
  500.       fields, with the exception of trace, can be regarded as
  501.       corresponding to implicit RFC 822 service elements.  A mechanism
  502.       of mapping used in several cases, is to place the text of the
  503.       header into the body of the IP Message.  This can usually be
  504.       regarded as partial support, as it allows the information to be
  505.       conveyed to the end user even though there is no corresponding
  506.       X.400 protocol element.  Support for the various service elements
  507.       (headers) is now listed.
  508.  
  509.  
  510.  
  511.  
  512. Kille                                                           [Page 9]
  513.  
  514.  
  515.  
  516. RFC 987                                                        June 1986
  517. Mapping between X.400 and RFC 822
  518.  
  519.  
  520.          Date:
  521.  
  522.             Supported.
  523.  
  524.          From:
  525.  
  526.             Supported.  For messages where there is also a sender field,
  527.             the mapping is to "Authorising Addresses", which has subtly
  528.             different semantics to the general RFC 822 usage of From:.
  529.  
  530.          Sender:
  531.  
  532.             Supported.
  533.  
  534.          Reply-To:
  535.  
  536.             Supported.
  537.  
  538.          To:
  539.  
  540.             Supported.
  541.  
  542.          Cc:
  543.  
  544.             Supported.
  545.  
  546.          Bcc:
  547.  
  548.             Supported.
  549.  
  550.          Message-Id:
  551.  
  552.             Supported.
  553.  
  554.          In-Reply-To:
  555.  
  556.             Supported, for a single reference in msg-id form.  Other
  557.             cases are passed in the message text.
  558.  
  559.          References:
  560.  
  561.             Supported.
  562.  
  563.          Keywords:
  564.  
  565.             Passed in the message text.
  566.  
  567.  
  568.  
  569. Kille                                                          [Page 10]
  570.  
  571.  
  572.  
  573. RFC 987                                                        June 1986
  574. Mapping between X.400 and RFC 822
  575.  
  576.  
  577.          Subject:
  578.  
  579.             Supported.
  580.  
  581.          Comments:
  582.  
  583.             Passed in the message text.
  584.  
  585.          Encrypted:
  586.  
  587.             Passed in the message text.  This may not be very useful.
  588.  
  589.          Resent-*
  590.  
  591.             Passed in the message text.  In principle, these could be
  592.             supported in a fuller manner, but this is not suggested.
  593.  
  594.          Other Fields
  595.  
  596.             In particular X-* fields, and "illegal" fields in common
  597.             usage (e.g. "Fruit-of-the-day:") are passed in the message
  598.             text.
  599.  
  600.    2.2.  X.400
  601.  
  602.       When mapping from X.400 to RFC 822, it is not proposed to map any
  603.       elements into the body of an RFC 822 message.  Rather, new RFC 822
  604.       headers are defined.  It is intended that these fields will be
  605.       registered, and that co-operating RFC 822 systems may use them.
  606.       Where these new fields are used, and no system action is implied,
  607.       the service can be regarded as being almost supported.  Chapter 5
  608.       describes how to map these new headers in both directions.  Other
  609.       elements are provided, in part, by the gateway as they cannot be
  610.       provided by RFC 822.  Some service elements are are marked N/A
  611.       (not applicable).  These elements are only applicable to User
  612.       Agent / Message Transfer Agent interaction and have no end-to-end
  613.       implication. These elements do not need to be mapped by the
  614.       gateway.
  615.  
  616.       2.2.1.  Message Transfer Service Elements
  617.  
  618.          Access Management
  619.  
  620.             N/A.
  621.  
  622.  
  623.  
  624.  
  625.  
  626. Kille                                                          [Page 11]
  627.  
  628.  
  629.  
  630. RFC 987                                                        June 1986
  631. Mapping between X.400 and RFC 822
  632.  
  633.  
  634.          Content Type Indication
  635.  
  636.             Not mapped.  As it can only have one value (P2), there is
  637.             little use in creating a new RFC 822 header field, unless it
  638.             was to distinguish delivery reports.
  639.  
  640.          Converted Indication
  641.  
  642.             Supported by a new RFC 822 header.
  643.  
  644.          Delivery Time Stamp Indication
  645.  
  646.             N/A.
  647.  
  648.          Message Identification
  649.  
  650.             Supported, by use of a new RFC 822 header.  This new header
  651.             is required, as X.400 has two message-ids whereas RFC 822
  652.             has only one.
  653.  
  654.          Non-delivery Notification
  655.  
  656.             Not supported, although in general an RFC 822 system will
  657.             return errors as IP messages.  In other elements, this
  658.             pragmatic result is treated as effective support of this
  659.             service element.
  660.  
  661.          Original Encoded Information Types Indication
  662.  
  663.             Supported as a new RFC 822 header.
  664.  
  665.          Registered Encoded Information Types
  666.  
  667.             N/A.
  668.  
  669.          Submission Time Stamp Indication
  670.  
  671.             Supported.
  672.  
  673.          Alternate Recipient Allowed
  674.  
  675.             Not supported.  Any value is ignored by the gateway.
  676.  
  677.          Deferred Delivery
  678.  
  679.             Support is optional.  The framework is provided so that
  680.             messages may be held at the gateway.  However, a gateway
  681.  
  682.  
  683. Kille                                                          [Page 12]
  684.  
  685.  
  686.  
  687. RFC 987                                                        June 1986
  688. Mapping between X.400 and RFC 822
  689.  
  690.  
  691.             following this specification does not have to do this.  This
  692.             is in line with the emerging functional standards.
  693.  
  694.          Deferred Delivery Cancellation
  695.  
  696.             Supported.
  697.  
  698.          Delivery Notification
  699.  
  700.             Supported at gateway.  Thus, a notification is sent by the
  701.             gateway to the originator  <2>.
  702.  
  703.          Disclosure of Other Recipients
  704.  
  705.             Supported by use of a new RFC 822 header.
  706.  
  707.          Grade of Delivery Selection
  708.  
  709.             Supported as a new RFC 822 header.  In general, this will
  710.             only be for user information in the RFC 822 world.
  711.  
  712.          Multi-Destination Delivery
  713.  
  714.             Supported.
  715.  
  716.          Prevention of Non-delivery Notification
  717.  
  718.             Not Supported, as there is no control in the RFC 822 world
  719.             (but see Non-delivery Notification).
  720.  
  721.          Return of Contents
  722.  
  723.             This is normally the case, although the user has no control
  724.             (but see Non-delivery Notification).
  725.  
  726.          Conversion Prohibition
  727.  
  728.             Supported.  Note that in practice this support is restricted
  729.             by the nature of the gateway.
  730.  
  731.          Explicit Conversion
  732.  
  733.             Supported, for appropriate values (See the IPMS Typed Body
  734.             service element).
  735.  
  736.  
  737.  
  738.  
  739.  
  740. Kille                                                          [Page 13]
  741.  
  742.  
  743.  
  744. RFC 987                                                        June 1986
  745. Mapping between X.400 and RFC 822
  746.  
  747.  
  748.          Implicit Conversion
  749.  
  750.             Supported, in the sense that there will be implicit
  751.             conversion to IA5 in cases where this is practical.
  752.  
  753.          Probe
  754.  
  755.             Supported at the gateway (i.e. the gateway services the
  756.             probe).
  757.  
  758.          Alternate Recipient Assignment
  759.  
  760.             N/A.
  761.  
  762.          Hold for Delivery
  763.  
  764.             N/A.
  765.  
  766.       2.2.2.  Interpersonal Message Service Elements
  767.  
  768.          IP-message Identification
  769.  
  770.             Supported.
  771.  
  772.          Typed Body
  773.  
  774.             Supported.  IA5 is fully supported.  ForwardedIPMessage is
  775.             supported, with some loss of information.  A subset of TTX
  776.             is supported (see section 5 for the specification of this
  777.             subset), with some loss of information.  SFD may be
  778.             supported, with some loss of information.  TTX and SFD are
  779.             only supported when conversion is allowed.  Other types are
  780.             not supported.
  781.  
  782.          Blind Copy Recipient Indication
  783.  
  784.             Supported.
  785.  
  786.          Non-receipt Notification
  787.  
  788.             Not supported.
  789.  
  790.          Receipt Notification
  791.  
  792.             Not supported.
  793.  
  794.  
  795.  
  796.  
  797. Kille                                                          [Page 14]
  798.  
  799.  
  800.  
  801. RFC 987                                                        June 1986
  802. Mapping between X.400 and RFC 822
  803.  
  804.  
  805.          Auto-forwarded Indication
  806.  
  807.             Supported as new RFC 822 header.
  808.  
  809.          Originator Indication
  810.  
  811.             Supported.
  812.  
  813.          Authorising User's Indication
  814.  
  815.             Supported, although the mapping (From:) is not quite the
  816.             same.
  817.  
  818.          Primary and Copy Recipients Indication
  819.  
  820.             Supported.
  821.  
  822.          Expiry Date Indication
  823.  
  824.             Supported as new RFC 822 header.  In general, only human
  825.             action can be expected.
  826.  
  827.          Cross Referencing Indication
  828.  
  829.             Supported.
  830.  
  831.          Importance Indication
  832.  
  833.             Supported as new RFC 822 header.
  834.  
  835.          Obsoleting Indication
  836.  
  837.             Supported as new RFC 822 header.
  838.  
  839.          Sensitivity Indication
  840.  
  841.             Supported as new RFC 822 header.
  842.  
  843.          Subject Indication
  844.  
  845.             Supported.
  846.  
  847.          Reply Request Indication
  848.  
  849.             Supported as comment next to address.
  850.  
  851.  
  852.  
  853.  
  854. Kille                                                          [Page 15]
  855.  
  856.  
  857.  
  858. RFC 987                                                        June 1986
  859. Mapping between X.400 and RFC 822
  860.  
  861.  
  862.          Forwarded IP-message Indication
  863.  
  864.             Supported, with some loss of information.
  865.  
  866.          Body Part Encryption Indication
  867.  
  868.             Not supported.
  869.  
  870.          Multi-part Body
  871.  
  872.             Supported, with some loss of information, in that the
  873.             structuring cannot be formalised in RFC 822.
  874.  
  875.  
  876.  
  877.  
  878.  
  879.  
  880.  
  881.  
  882.  
  883.  
  884.  
  885.  
  886.  
  887.  
  888.  
  889.  
  890.  
  891.  
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898.  
  899.  
  900.  
  901.  
  902.  
  903.  
  904.  
  905.  
  906.  
  907.  
  908.  
  909.  
  910.  
  911. Kille                                                          [Page 16]
  912.  
  913.  
  914.  
  915. RFC 987                                                        June 1986
  916. Mapping between X.400 and RFC 822
  917.  
  918.  
  919. Chapter 3 -- Basic Mappings
  920.  
  921.    3.1.  Notation
  922.  
  923.       The P1 and P2 protocols are encoded in a structured manner
  924.       according to the X.409 specifications, whereas RFC 822 is text
  925.       encoded.  To define a detailed mapping, it is necessary to refer
  926.       to detailed protocol elements in each format.  This is described.
  927.  
  928.       3.1.4.  RFC 822
  929.  
  930.          Structured text is defined according to the Extended Backus
  931.          Naur Form (EBNF) defined in section 2 of RFC 822 [Crocker82a].
  932.          In the EBNF definitions used in this specification, the syntax
  933.          rules given in Appendix D of RFC 822 are assumed.  When these
  934.          EBNF tokens are referred to outside an EBNF definition, they
  935.          are identified by the string "882." appended to the beginning
  936.          of the string (e.g. 822.addr-spec).  Additional syntax rules,
  937.          to be used throughout this specification are defined in this
  938.          chapter.
  939.  
  940.          The EBNF is used in two ways.
  941.  
  942.             1.   To describe components of RFC 822 messages (or of
  943.                  822-P1 components).  In this case, the lexical analysis
  944.                  defined in section 3 of RFC 822 should be used.  When
  945.                  these new EBNF tokens are referred to outside an EBNF
  946.                  definition, they are identified by the string "EBNF."
  947.                  appended to the beginning of the string (e.g.
  948.                  EBNF.bilateral-info).
  949.  
  950.             2.   To describe the structure of IA5 or ASCII information
  951.                  not in an RFC 822 message.  In these cases, tokens will
  952.                  either be self delimiting, or be delimited by self
  953.                  delimiting tokens.  Comments and LWSP are not used as
  954.                  delimiters.
  955.  
  956.       3.1.5.  X.409
  957.  
  958.          An element is referred to with the following syntax, defined in
  959.          EBNF:
  960.  
  961.             element        = protocol "." definition *( "." definition )
  962.             protocol       = "P1" / "P2"
  963.             definition     = identifier / context
  964.             identifier     = ALPHA *< ALPHA or DIGIT or "-" >
  965.             context        = "[" 1*DIGIT "]"
  966.  
  967.  
  968. Kille                                                          [Page 17]
  969.  
  970.  
  971.  
  972. RFC 987                                                        June 1986
  973. Mapping between X.400 and RFC 822
  974.  
  975.  
  976.          For example, P2.Heading.subject defines the subject element of
  977.          the P2 heading.  The same syntax is also used to refer to
  978.          element values. For example,
  979.          P1.EncodedInformationTypes.[0].g3Fax refers to a value of
  980.          P1.EncodedInformationTypes.[0] .
  981.  
  982.    3.2.  ASCII and IA5
  983.  
  984.       A gateway will interpret all IA5 as ASCII.  Thus, they are treated
  985.       identically for the rest of this document.
  986.  
  987.    3.3.  Universal Primitives
  988.  
  989.       There is a need to convert between ASCII text, and some of the
  990.       Universal Primitive types defined in X.409 [CCITT84d].  For each
  991.       case, an EBNF syntax definition is given, for use in all of this
  992.       specification.  All EBNF syntax definitions of Universal
  993.       Primitives are in lower case, whereas X.409 primitives are
  994.       referred to with the first letter in upper case.  Except as noted,
  995.       all mappings are symmetrical.
  996.  
  997.       3.3.1.  Boolean
  998.  
  999.          Boolean is encoded as:
  1000.  
  1001.             boolean = "TRUE" / "FALSE"
  1002.  
  1003.       3.3.2.  NumericString
  1004.  
  1005.          NumericString is encoded as:
  1006.  
  1007.             numericstring = *DIGIT
  1008.  
  1009.       3.3.3.  PrintableString
  1010.  
  1011.          PrintableString is a restricted IA5String defined as:
  1012.  
  1013.             printablestring  = *( ps-char / ps-delim )
  1014.  
  1015.             ps-char          = 1DIGIT /  1ALPHA / " " / "'" / "+" / ")"
  1016.                                / "," / "-" / "." / "/" / ":" / "=" / "?"
  1017.  
  1018.             ps-delim         = "("
  1019.  
  1020.          A structured subset of EBNF.printablestring is now defined.
  1021.          This can be used to encode ASCII in the PrintableString
  1022.          character set.
  1023.  
  1024.  
  1025. Kille                                                          [Page 18]
  1026.  
  1027.  
  1028.  
  1029. RFC 987                                                        June 1986
  1030. Mapping between X.400 and RFC 822
  1031.  
  1032.  
  1033.             ps-encoded       = *( ps-char / ps-encoded-char )
  1034.  
  1035.             ps-encoded-char  =   "(a)"               ; (@)
  1036.                                / "(p)"               ; (%)
  1037.                                / "(b)"               ; (!)
  1038.                                / "(q)"               ; (")
  1039.                                / "(u)"               ; (_)
  1040.                                / "(" 3DIGIT ")"
  1041.  
  1042.          The 822.3DIGIT in EBNF.ps-encoded-char must have range 0-127
  1043.          (Decimal), and is interpreted in decimal as the corresponding
  1044.          ASCII character. Special encodings are given for: at sign (@),
  1045.          percent (%), exclamation mark/bang (!), double quote ("), and
  1046.          underscore (_).  These characters are not included in
  1047.          PrintableString, but are common in RFC 822 addresses.  The
  1048.          abbreviations will ease specification of RFC 822 addresses from
  1049.          an X.400 system.
  1050.  
  1051.          An asymmetric mapping between PrintableString and ASCII can now
  1052.          be defined <3>.  To encode ASCII as PrintableString, the
  1053.          EBNF.ps-encoded syntax is used, with all EBNF.ps-char AND
  1054.          EBNF.ps-delim mapped directly <4>.  All other 822.CHAR are
  1055.          encoded as EBNF.ps-encoded-char. There are two cases of
  1056.          encoding PrintableString as ASCII.  If the PrintableString can
  1057.          be parsed as EBNF.ps-encoded, then the previous mapping should
  1058.          be reversed.  If not, it should be interpreted as
  1059.          EBNF.printablestring.
  1060.  
  1061.          Some examples are now given.  Note the arrows which indicate
  1062.          asymmetrical mappings:
  1063.  
  1064.             PrintableString           ASCII
  1065.  
  1066.             'a demo.'         <->   'a demo.'
  1067.             foo(a)bar         <->   foo@bar
  1068.  
  1069.             (q)(u)(p)(q)      <->   "_%"
  1070.             (a)               <->   @
  1071.             (a)               <-    (a)
  1072.             (040)a(041)       ->    (a)
  1073.             (040)(a)          ->    (@
  1074.             ((a)              <-    (@
  1075.  
  1076.          The algorithm is designed so that it is simple to use in all
  1077.          common cases, so that it is general, and so that it is
  1078.          straightforward to code.  It is not attempting to minimise the
  1079.          number of pathological cases.
  1080.  
  1081.  
  1082. Kille                                                          [Page 19]
  1083.  
  1084.  
  1085.  
  1086. RFC 987                                                        June 1986
  1087. Mapping between X.400 and RFC 822
  1088.  
  1089.  
  1090.       3.3.4.  T.61String
  1091.  
  1092.          T.61 strings are, in general, only used for conveying human
  1093.          interpreted information.  Thus, the aim of a mapping should be
  1094.          to render the characters appropriately in the remote character
  1095.          set, rather than to maximise reversibility.  The mappings
  1096.          defined in the CEN/CENELEC X.400 functional standard should be
  1097.          used [CEN/CENELEC/85a].  These are based on the mappings of
  1098.          X.408 (sections 4.2.2 and 5.2.2).
  1099.  
  1100.       3.3.5.  UTCTime
  1101.  
  1102.          Both UTCTime and the RFC 822 822.date-time syntax contain: Year
  1103.          (lowest two digits), Month, Day of Month, hour, minute, second
  1104.          (optional), and Timezone.  822.date-time also contains an
  1105.          optional day of the week, but this is redundant.  Therefore a
  1106.          symmetrical mapping can be made between these constructs <5>.
  1107.          The UTCTime format which specifies the timezone offset should
  1108.          be used, in line with CEN/CENELEC recommendations.
  1109.  
  1110.  
  1111.  
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122.  
  1123.  
  1124.  
  1125.  
  1126.  
  1127.  
  1128.  
  1129.  
  1130.  
  1131.  
  1132.  
  1133.  
  1134.  
  1135.  
  1136.  
  1137.  
  1138.  
  1139. Kille                                                          [Page 20]
  1140.  
  1141.  
  1142.  
  1143. RFC 987                                                        June 1986
  1144. Mapping between X.400 and RFC 822
  1145.  
  1146.  
  1147. Chapter 4 -- Addressing
  1148.  
  1149.    Addressing is probably the trickiest problem of an X.400 <-> RFC 822
  1150.    gateway.  Therefore it is given a separate chapter.  This chapter, as
  1151.    a side effect, also defines a standard textual representation of
  1152.    X.400 addresses.
  1153.  
  1154.    Initially we consider an address in the (human) mail user sense of
  1155.    "what is typed at the mailsystem to reference a human".  A basic
  1156.    RFC 822 address is defined by the EBNF EBNF.822-address:
  1157.  
  1158.       822-address     = [ route ] addr-spec
  1159.  
  1160.    In an 822-P1 protocol, the originator and each recipient should be
  1161.    considered to be defined by such a construct.  In an RFC 822 header,
  1162.    the EBNF.822-address is encapsulated in the 822.address syntax rule,
  1163.    and there may also be associated comments.  None of this extra
  1164.    information has any semantics, other than to the end user.
  1165.  
  1166.    The basic X.400 address is defined by P1.ORName.  In P1 all recipient
  1167.    P1.ORnames are encapsulated within P1.RecipientInfo, and in P2 all
  1168.    P2.ORNames <6> are encapsulated within P2.ORDescriptor.
  1169.  
  1170.    It can be seen that RFC 822 822.address must be mapped with
  1171.    P2.ORDescriptor, and that RFC 822 EBNF.822-address must be mapped
  1172.    with P1.ORName (originator) and P1.RecipientInfo (recipients).
  1173.  
  1174.    This chapter is structured as follows:
  1175.  
  1176.       4.1  Introduction.
  1177.  
  1178.       4.2  A textual representation of P1.ORName.  This is needed for
  1179.            the later mappings, and as a side effect provides a standard
  1180.            representation for O/R names.
  1181.  
  1182.       4.3  Mapping between EBNF.822-address and P1.ORName
  1183.  
  1184.       4.4  The Full P1 / 822-P1 Mapping
  1185.  
  1186.       4.5  The Full P2 / RFC 822 Mapping
  1187.  
  1188.       4.6  Mapping Message-IDs.
  1189.  
  1190.  
  1191.  
  1192.  
  1193.  
  1194.  
  1195.  
  1196. Kille                                                          [Page 21]
  1197.  
  1198.  
  1199.  
  1200. RFC 987                                                        June 1986
  1201. Mapping between X.400 and RFC 822
  1202.  
  1203.  
  1204.    4.1.  A textual representation of P1.ORName.
  1205.  
  1206.       P1.ORName is structured as a set of attribute value pairs.  It is
  1207.       clearly necessary to be able to encode this in ASCII for
  1208.       gatewaying purposes.  A general encoding is given here, which may
  1209.       be used as a basis for a user interface, as well as for the
  1210.       defined gateway mapping.
  1211.  
  1212.       4.1.1.  Basic Representation
  1213.  
  1214.          A series of BNF definitions of each possible attribute value
  1215.          pair is given, which is given a 1:1 mapping with the X.400
  1216.          encoding.  The rest of the mapping then talks in terms of these
  1217.          BNF components, with the mapping to X.400 encoding being
  1218.          trivial.
  1219.  
  1220.          attributevalue = c / admd / prmd / x121 / t-id / o / ou
  1221.                          / ua-id / pn.g / pn.i / pn.s / pn.gq / dd.value
  1222.  
  1223.          c        = printablestring       ; P1.CountryName
  1224.          admd     = printablestring       ; P1.AdministrationDomainName
  1225.          prmd     = printablestring       ; P1.PrivateDomainName
  1226.          x121     = numericstring         ; P1.X121Address
  1227.          t-id     = numericstring         ; P1.TerminalID
  1228.          o        = printablestring       ; P1.OrganisationName
  1229.          ou       = printablestring       ; P1.OrganisationalUnit
  1230.          ua-id    = numericstring         ; P1.UniqueUAIdentifier
  1231.          pn.s     = printablestring       ; P1.PersonalName.surName
  1232.          pn.g     = printablestring       ; P1.PersonalName.givenName
  1233.          pn.i     = printablestring       ; P1.PersonalName.initials
  1234.          pn.gq    = printablestring       ; P1.PersonalName.generation
  1235.                                             Qualifier
  1236.          dd.value = printablestring       ; P1.DomainDefined
  1237.                                             Attribute.value
  1238.  
  1239.          In cases where an attribute can be encoded as either a
  1240.          PrintableString or NumericString (Country, ADMD, PRMD) it is
  1241.          assumed that the NumericString encoding will be adopted if
  1242.          possible.  This prevents the encoding of PrintableString where
  1243.          the characters are all numbers. This restriction seems
  1244.          preferable to the added complexity of a general solution.
  1245.          Similarly, we can define a set of attribute types.
  1246.  
  1247.  
  1248.  
  1249.  
  1250.  
  1251.  
  1252.  
  1253. Kille                                                          [Page 22]
  1254.  
  1255.  
  1256.  
  1257. RFC 987                                                        June 1986
  1258. Mapping between X.400 and RFC 822
  1259.  
  1260.  
  1261.          dd.type = printablestring      ; P1.DomainDefinedAttribute.type
  1262.  
  1263.          standard-type =
  1264.                    "C"           ; P1.CountryName
  1265.                  / "ADMD"        ; P1.AdministrationDomainName
  1266.                  / "PRMD"        ; P1.PrivateDomainName
  1267.                  / "X121"        ; P1.X121Address
  1268.                  / "T-ID"        ; P1.TerminalID
  1269.                  / "O"           ; P1.OrganisationName
  1270.                  / "OU"          ; P1.OrganisationalUnit
  1271.                  / "UA-ID"       ; P1.UniqueUAIdentifier
  1272.                  / "S"           ; P1.PersonalName.surName
  1273.                  / "G"           ; P1.PersonalName.givenName
  1274.                  / "I"           ; P1.PersonalName.initials
  1275.                  / "GQ"          ; P1.PersonalName.generationQualifier
  1276.  
  1277.          standard-dd-type =
  1278.                    "RFC-822"     ; dd.type = "RFC-822"
  1279.                  / "JNT-Mail"    ; dd.type = "JNT-Mail"
  1280.                  / "UUCP"        ; dd.type = "UUCP"
  1281.  
  1282.       4.1.2.  Encoding of Personal Name
  1283.  
  1284.          Handling of Personal Name based purely on the
  1285.          EBNF.standard-type syntax defined above is likely to be clumsy.
  1286.          It seems desirable to utilise the "human" conventions for
  1287.          encoding these components.  A syntax is proposed here.  It is
  1288.          designed to cope with the common cases of O/R Name
  1289.          specification where:
  1290.  
  1291.             1.   There is no generational qualifier
  1292.  
  1293.             2.   Initials contain only letters <7>.
  1294.  
  1295.             3.   Given Name does not contain full stop ("."), and is at
  1296.                  least two characters long.
  1297.  
  1298.             4.   If Surname contains full stop, then it may not be in
  1299.                  the first two characters, and either initials or given
  1300.                  name is present.
  1301.  
  1302.  
  1303.  
  1304.  
  1305.  
  1306.  
  1307.  
  1308.  
  1309.  
  1310. Kille                                                          [Page 23]
  1311.  
  1312.  
  1313.  
  1314. RFC 987                                                        June 1986
  1315. Mapping between X.400 and RFC 822
  1316.  
  1317.  
  1318.          The following EBNF is defined:
  1319.  
  1320.             encoded-pn      = [ given "." ] *( initial "." ) surname
  1321.  
  1322.             given           = 2*<ps-char not including ".">
  1323.  
  1324.             initial         = ALPHA
  1325.  
  1326.             surname         = printablestring
  1327.  
  1328.          Subject to the above restriction, this is a reversible mapping.
  1329.  
  1330.          For example:
  1331.  
  1332.             GivenName       = "Marshall"
  1333.             Surname         = "Rose"
  1334.  
  1335.             Maps with  "Marshall.Rose"
  1336.  
  1337.             Initials        = "MT"
  1338.             Surname         = "Rose"
  1339.  
  1340.             Maps with  "M.T.Rose"
  1341.  
  1342.             GivenName       = "Marshall"
  1343.             Initials        = "MT"
  1344.             Surname         = "Rose"
  1345.  
  1346.             Maps with  "Marshall.M.T.Rose"
  1347.  
  1348.          Note that CCITT guidelines suggest that Initials is used to
  1349.          encode ALL initials.  Therefore, the proposed encoding is
  1350.          "natural" when either GivenName or Initials, but not both, are
  1351.          present.  The case where both are present can be encoded, but
  1352.          this appears to be contrived!
  1353.  
  1354.       4.1.3.  Two encodings of P1.ORName
  1355.  
  1356.          Given this structure, we can specify a BNF representation of an
  1357.          O/R Name.
  1358.  
  1359.  
  1360.  
  1361.  
  1362.  
  1363.  
  1364.  
  1365.  
  1366.  
  1367. Kille                                                          [Page 24]
  1368.  
  1369.  
  1370.  
  1371. RFC 987                                                        June 1986
  1372. Mapping between X.400 and RFC 822
  1373.  
  1374.  
  1375.             std-orname      = 1*( "/" attribute "=" value ) "/"
  1376.             attribute       = standard-type
  1377.                             / "PN"
  1378.                             / standard-dd-type
  1379.                             / registered-dd-type
  1380.                             / "DD." std-printablestring
  1381.             value           = std-printablestring
  1382.             registered-dd-type
  1383.                             = std-printablestring
  1384.             std-printablestring =
  1385.                             = *( std-char / std-pair )
  1386.             std-char        = <ps-delim, and any ps-char except "/"
  1387.                               and "=">
  1388.             std-pair        = "$" ( ps-delim / ps-char )
  1389.  
  1390.          If the type is PN, the value is interpreted according to
  1391.          EBNF.encoded-pn, and the components of P1.PersonalName derived
  1392.          accordingly.  If the value is registered-dd-type, if the value
  1393.          is registered at the SRI NIC as an accepted Domain Defined
  1394.          Attribute type, then the value should be interpreted
  1395.          accordingly.  This restriction maximises the syntax checking
  1396.          which can be done at a gateway.
  1397.  
  1398.          Another syntax is now defined.  This is intended to be
  1399.          compatible with the syntax used for 822.domains.  This syntax
  1400.          is not intended to be handled by users.
  1401.  
  1402.             dmn-orname      = dmn-part *( "." dmn-part )
  1403.             dmn-part        = attribute "$" value
  1404.             attribute       = standard-type
  1405.                             / "~" dmn-printablestring
  1406.             value           = dmn-printablestring
  1407.             dmn-printablestring =
  1408.                             = *( dmn-char / dmn-pair )
  1409.             dmn-char        = <ps-delim, and any ps-char except ".">
  1410.             dmn-pair        = "\."
  1411.  
  1412.          For example: C$US.ADMD$ATT.~ROLE$Big\.Chief
  1413.  
  1414.  
  1415.  
  1416.  
  1417.  
  1418.  
  1419.  
  1420.  
  1421.  
  1422.  
  1423.  
  1424. Kille                                                          [Page 25]
  1425.  
  1426.  
  1427.  
  1428. RFC 987                                                        June 1986
  1429. Mapping between X.400 and RFC 822
  1430.  
  1431.  
  1432.    4.2.  Mapping between EBNF.822-address and P1.ORName
  1433.  
  1434.       Ideally, the mapping specified would be entirely symmetrical and
  1435.       global, to enable addresses to be referred to transparently in the
  1436.       remote system, with the choice of gateway being left to the
  1437.       Message Transfer Service.  There are two fundamental reasons why
  1438.       this is not possible:
  1439.  
  1440.          1.   The syntaxes are sufficiently different to make this
  1441.               awkward.
  1442.  
  1443.          2.   In the general case, there would not be the necessary
  1444.               administrative co-operation between the X.400 and RFC 822
  1445.               worlds, which would be needed for this to work.
  1446.  
  1447.       Therefore, an asymmetrical mapping is defined.
  1448.  
  1449.       4.2.1.  X.400 encoded in RFC 822
  1450.  
  1451.          The std-orname syntax is  used to encode O/R Name information
  1452.          in the 822.local-part of EBNF.822-address.  Further  O/R Name
  1453.          information may be associated with the 822.domain component.
  1454.          This cannot be used in the general case, basically due to
  1455.          character set problems, and lack of order in X.400 O/R Names.
  1456.          The only way to encode the full PrintableString character set
  1457.          in a domain is by use of the 822.domain-ref syntax.  This is
  1458.          likely to cause problems on many systems.  The effective
  1459.          character set of domains is in practice reduced from the
  1460.          RFC 822 set, by restrictions imposed by domain conventions and
  1461.          policy.
  1462.  
  1463.          A generic 822.address consists of a 822.local-part and a
  1464.          sequence of 822.domains (e.g.
  1465.          <@domain1,@domain2:user@domain3>).  All except the 822.domain
  1466.          associated with the 822.local-part (domain3 in this case)
  1467.          should be considered to specify routing within the RFC 822
  1468.          world, and will not be interpreted by the gateway (although
  1469.          they may have identified the gateway from within the RFC 822
  1470.          world).  The 822.domain associated with the 822.local-part may
  1471.          also identify the gateway from within the RFC 822 world.  This
  1472.          final 822.domain may be used to determine some number of O/R
  1473.          Name attributes.  The following O/R Name attributes are
  1474.          considered as a hierarchy, and may be specified by the domain.
  1475.          They are (in order of hierarchy):
  1476.  
  1477.             Country, ADMD, PRMD, Organisation, Organisational Unit
  1478.  
  1479.  
  1480.  
  1481. Kille                                                          [Page 26]
  1482.  
  1483.  
  1484.  
  1485. RFC 987                                                        June 1986
  1486. Mapping between X.400 and RFC 822
  1487.  
  1488.  
  1489.          There may be multiple Organisational Units.
  1490.  
  1491.          Associations may be defined between domain specifications, and
  1492.          some set of attributes.  This association proceeds
  1493.          hierarchically: i.e. if a domain implies ADMD, it also implies
  1494.          country.  If one of the hierarchical components is omitted from
  1495.          an X.400 structure, this information can be associated with the
  1496.          corresponding domain (e.g. a domain can be mapped onto a
  1497.          Country/ADMD/Organisation tuple). Subdomains under this are
  1498.          associated according to the O/R Name hierarchy.  For example:
  1499.  
  1500.             => "AC.UK" might be associated with
  1501.                                           C="234", ADMD="BT", PRMD="DES"
  1502.  
  1503.             then domain "R-D.Salford.AC.UK" maps with
  1504.                    C="234", ADMD="BT", PRMD="DES", O="Salford", OU="R-D"
  1505.  
  1506.          There are two basic reasons why a domain/attribute mapping
  1507.          might be maintained, as opposed to using simply subdomains:
  1508.  
  1509.             1.   As a shorthand to avoid redundant X.400 information.
  1510.                  In particular, there will often be only one ADMD per
  1511.                  country, and so it does not need to be given
  1512.                  explicitly.
  1513.  
  1514.             2.   To deal with cases where attribute values do not fit
  1515.                  the syntax:
  1516.  
  1517.                domain-syntax   = ALPHA [ *alphanumhyphen alphanum ]
  1518.                alphanum        = <ALPHA or DIGIT>
  1519.                alphanumhyphen  = <ALPHA or DIGIT or HYPHEN>
  1520.  
  1521.          Although RFC 822 allows for a more general syntax, this
  1522.          restriced syntax is chosen as it is the one chosen by the
  1523.          various domain service administrations.
  1524.  
  1525.          This provides a general aliasing mechanism.
  1526.  
  1527.          This set of mappings need only be known by the gateways
  1528.          relaying between the RFC 822 world, and the O/R Name namespace
  1529.          associated with the mapping in question.  However, it is
  1530.          desirable (for the optimal mapping of third party addresses)
  1531.          for all gateways to know these mappings.  A format for the
  1532.          exchange of this information is defined in Appendix F.
  1533.  
  1534.          From the standpoint of the RFC 822 Message Transfer System, the
  1535.          domain specification is simply used to route the message in the
  1536.  
  1537.  
  1538. Kille                                                          [Page 27]
  1539.  
  1540.  
  1541.  
  1542. RFC 987                                                        June 1986
  1543. Mapping between X.400 and RFC 822
  1544.  
  1545.  
  1546.          standard manner.  The standard domain mechanisms are used to
  1547.          identify gateways, and are used to select appropriate gateways
  1548.          for the corresponding O/R Name namespace.  In most cases, this
  1549.          will be done by registering the higher levels, and assuming
  1550.          that the gateway can handle the lower levels.
  1551.  
  1552.          As a further mechanism to simplify the encoding of common
  1553.          cases, where the only attributes to be encoded on the LHS are
  1554.          Personal Name attributes which comply with the restrictions of
  1555.          4.2.2, the 822.local-part may be encoded as EBNF.encoded-pn.
  1556.  
  1557.          An example encoding is:
  1558.  
  1559.             /PN=J.Linnimouth/GQ=5/@Marketing.Xerox.COM
  1560.  
  1561.             encodes the P1.ORName consisting of
  1562.  
  1563.                P1.CountryName                  = "US"
  1564.                P1.AdministrationDomainName     = "ATT"
  1565.                P1.OrganisationName             = "Xerox"
  1566.                P1.OrganisationalUnit           = "Marketing"
  1567.                P1.PersonalName.surName         = "Linnimouth"
  1568.                P1.PersonalName.initials        = "J"
  1569.                P1.PersonalName.GenerationQualifier = "5"
  1570.  
  1571.             If the GenerationQualifier was not present, the encoding
  1572.             J.Linnimouth@Marketing.Xerox.COM could be used.
  1573.  
  1574.          Note that in this example, the first three attributes are
  1575.          determined by the domain Xerox.COM.  The OrganisationalUnit is
  1576.          determined systematically.
  1577.  
  1578.          There has been an implicit assumption that an RFC 822 domain is
  1579.          either X.400 or RFC 822.  This is pragmatic, but undesirable,
  1580.          as the namespace should be structured on a logical basis which
  1581.          does not necessarily correspond to the choice of Message
  1582.          Transfer protocols. The restriction can be lifted, provided
  1583.          that the nameservice deals with multiple message transfer
  1584.          protocols.  This can happen in a straightforward manner for the
  1585.          UK NRS, as explained in [Kille86a].  It could also be achieved
  1586.          with the DARPA Domain Nameserver scheme by use of the WKS
  1587.          mechanism.
  1588.  
  1589.  
  1590.  
  1591.  
  1592.  
  1593.  
  1594.  
  1595. Kille                                                          [Page 28]
  1596.  
  1597.  
  1598.  
  1599. RFC 987                                                        June 1986
  1600. Mapping between X.400 and RFC 822
  1601.  
  1602.  
  1603.       4.2.2.  RFC 822 Encoded in X.400
  1604.  
  1605.          In some cases, the encoding defined above may be reversed, to
  1606.          give a "natural" encoding of genuine RFC 822 addresses.  This
  1607.          depends largely on the allocation of appropriate management
  1608.          domains.
  1609.  
  1610.          The general case is mapped by use of domain defined attributes.
  1611.          Three are defined, according to the full environment used to
  1612.          interpret the RFC 822 information.
  1613.  
  1614.             1.   Domain defined type "RFC-822".  This string is to be
  1615.                  interpreted in the context of RFC 822, and RFC 920
  1616.                  [Crocker82a,Postel84a].
  1617.  
  1618.             2.   Domain defined type "JNT-Mail".  This string is to be
  1619.                  interpreted in the context of the JNT Mail protocol,
  1620.                  and the NRS [Kille84a,Larmouth83a].
  1621.  
  1622.             3.   Domain defined type "UUCP".  This is interpreted
  1623.                  according to the constraints of the UUCP world
  1624.                  [Horton86a].
  1625.  
  1626.          These three are values currently known to be of use.  Further
  1627.          recognised values may be defined.  These will be maintained in
  1628.          a list at the SRI Network Information Center.
  1629.  
  1630.          Other O/R Name attributes will be used to identify a context in
  1631.          which the O/R Name will be interpreted.  This might be a
  1632.          Management Domain, or some part of a Management Domain which
  1633.          identifies a gateway MTA.  For example:
  1634.  
  1635.             1)
  1636.  
  1637.             C               = "GB"
  1638.             ADMD            = "BT"
  1639.             PRMD            = "AC"
  1640.             "JNT-Mail"      = "Jimmy(a)UK.CO.BT-RESEARCH-LABS"
  1641.  
  1642.             2)
  1643.  
  1644.             C               = "US"
  1645.             ADMD            = "Telemail"
  1646.             PRMD            = "San Fransisco"
  1647.             O               = "U Cal"
  1648.             OU              = "Berkeley"
  1649.             "RFC-822"       = "postel(a)usc-isib.arpa"
  1650.  
  1651.  
  1652. Kille                                                          [Page 29]
  1653.  
  1654.  
  1655.  
  1656. RFC 987                                                        June 1986
  1657. Mapping between X.400 and RFC 822
  1658.  
  1659.  
  1660.          Note in each case the PrintableString encoding of "@" as "(a)".
  1661.          In the first example, the "JNT-Mail" domain defined attribute
  1662.          is interpreted everywhere within the (Administrative or
  1663.          Private) Management Domain.  In the second example, further
  1664.          attributes are needed within the Management Domain to identify
  1665.          a gateway.  Thus, this scheme can be used with varying levels
  1666.          of Management Domain co-operation.
  1667.  
  1668.       4.2.3.  RFC 822 -> X.400
  1669.  
  1670.          There are two basic cases:
  1671.  
  1672.             1.   X.400 addresses encoded in RFC 822.  This will also
  1673.                  include RFC 822 addresses which are given reversible
  1674.                  encodings.
  1675.  
  1676.             2.   "Genuine" RFC 822 addresses.
  1677.  
  1678.          The mapping should proceed as follows, by first assuming case
  1679.          1).
  1680.  
  1681.          STAGE 1.
  1682.  
  1683.             1.   If the 822-address is not of the form:
  1684.  
  1685.                local-part "@" domain
  1686.  
  1687.                go to stage 2.
  1688.  
  1689.             2.   Attempt to parse domain as:
  1690.  
  1691.                *( domain-syntax "." ) known-domain
  1692.  
  1693.                Where known-domain is the longest possible match in a
  1694.                list of gatewayed domains.  If this fails, and the domain
  1695.                does not explicitly identify the local gateway, go to
  1696.                stage 2.  If it succeeds, allocate the attributes
  1697.                associated with EBNF.known-domain, and systematically
  1698.                allocate the attributes implied by each
  1699.                EBNF.domain-syntax component.
  1700.  
  1701.             3.   Map 822.local-part to ASCII, according to the
  1702.                  definition of Appendix A.  This step should be applied:
  1703.  
  1704.                A.  If the source network cannot support
  1705.                    822.quoted-string (as discussed in Appendix A).
  1706.  
  1707.  
  1708.  
  1709. Kille                                                          [Page 30]
  1710.  
  1711.  
  1712.  
  1713. RFC 987                                                        June 1986
  1714. Mapping between X.400 and RFC 822
  1715.  
  1716.  
  1717.                B.  If the address is an 822-P1 recipient.
  1718.  
  1719.                   This mapping is always applied in case B, as it
  1720.                   increases the functionality of the gateway, and does
  1721.                   not imply any loss of generality.  Mapping case B
  1722.                   allows sites which cannot generate 822.quoted-string
  1723.                   to address recipients the gateway, without the gateway
  1724.                   having to know this explicitly.  There is no loss of
  1725.                   functionality, as the quoting character of Appendix A
  1726.                   (#) is not in PrintableString.  This seems desirable.
  1727.                   It should not be applied in to other addresses, as a
  1728.                   third party RFC#822 address containing the sequence
  1729.                   EBNF.atom-encoded (as defined in Appendix A) would be
  1730.                   transformed asymmetrically.
  1731.  
  1732.             4.   Map the result of 3) to EBNF.ps-encoded according to
  1733.                  section 3.
  1734.  
  1735.             5.   Parse the result of 4) according to the EBNF
  1736.                  EBNF.std-orname.  If this parse fails, parse the result
  1737.                  of 4) according to the EBNF EBNF.encoded-pn.  If this
  1738.                  also fails, go to stage 2.  Otherwise, the result is a
  1739.                  set of type/value pairs.
  1740.  
  1741.             6.   Associate the EBNF.attribute-value syntax (determined
  1742.                  from the identified type) with each value, and check
  1743.                  that it conforms.  If not, go to stage 2.
  1744.  
  1745.             7.   Ensure that the set of attributes conforms both to the
  1746.                  X.411 P1.ORName specification and to the restrictions
  1747.                  on this set given in X.400.  If not go to stage 2.
  1748.  
  1749.             8.   Build the O/R Name from this information.
  1750.  
  1751.          STAGE 2.
  1752.  
  1753.          This will only be reached if the RFC 822 EBNF.822-address is
  1754.          not a valid X.400 encoding.  If the address is an 822-P1
  1755.          recipient address, it must be rejected, as there is a need to
  1756.          interpret such an address in X.400.  For the 822-P1 return
  1757.          address, and any addresses in the RFC 822 header, they should
  1758.          now be encoded as RFC 822 addresses in an X.400 O/R Name:
  1759.  
  1760.             1.   Convert the EBNF.822-address to PrintableString, as
  1761.                  specified in chapter 3.
  1762.  
  1763.             2.   The domain defined attribute ("RFC-822", "JNT-Mail" or
  1764.  
  1765.  
  1766. Kille                                                          [Page 31]
  1767.  
  1768.  
  1769.  
  1770. RFC 987                                                        June 1986
  1771. Mapping between X.400 and RFC 822
  1772.  
  1773.  
  1774.                  "UUCP") appropriate to the gateway should be selected,
  1775.                  and its value set.
  1776.  
  1777.             3.   Build the rest of the O/R Name in the local Management
  1778.                  Domain agreed manner, so that the O/R Name will receive
  1779.                  a correct global interpretation.
  1780.  
  1781.       4.2.4.  X.400 -> RFC 822
  1782.  
  1783.          There are two basic cases:
  1784.  
  1785.             1.   RFC 822 addresses encoded in X.400.
  1786.  
  1787.             2.   "Genuine" X.400 addresses.  This may include
  1788.                  symmetrically encoded RFC 822 addresses.
  1789.  
  1790.          When a P1 Recipient O/R Name is interpreted, gatewaying will be
  1791.          selected if there a single special domain defined attribute
  1792.          present ("RFC-822", "JNT-Mail" or "UUCP").  In this case, use
  1793.          mapping A.  For other O/R Names which
  1794.  
  1795.             1.   Contain the special attribute.
  1796.  
  1797.                AND
  1798.  
  1799.             2.   Identify the local gateway with the other attributes.
  1800.  
  1801.          Use mapping A.  In other cases, use mapping B.
  1802.  
  1803.          Mapping A
  1804.  
  1805.             1.   Map the domain defined attribute value to ASCII, as
  1806.                  defined in chapter 3.
  1807.  
  1808.             2.   Where appropriate (P1 recipients), interpret the string
  1809.                  according to the semantics implied by the domain
  1810.                  defined attribute.
  1811.  
  1812.          Mapping B.
  1813.  
  1814.          This will be used for X.400 addresses which do not use the
  1815.          explicit RFC 822 encoding.
  1816.  
  1817.             1.   Noting the hierarchy specified in 4.3.1, determine the
  1818.                  maximum set of attributes which have an associated
  1819.                  domain specification. If no match is found, allocate
  1820.  
  1821.  
  1822.  
  1823. Kille                                                          [Page 32]
  1824.  
  1825.  
  1826.  
  1827. RFC 987                                                        June 1986
  1828. Mapping between X.400 and RFC 822
  1829.  
  1830.  
  1831.                  the domain as the domain specification of the local
  1832.                  gateway, and go to step 4.
  1833.  
  1834.             2.   Following the 4.3.1 hierarchy, if each successive
  1835.                  component exists, and conforms to the syntax
  1836.                  EBNF.domain-syntax (as defined in 4.3.1), allocate the
  1837.                  next subdomain.
  1838.  
  1839.             3.   If the remaining components are personal-name
  1840.                  components, conforming to the restrictions of 4.2.2,
  1841.                  then EBNF.encoded-pn should be derived to form
  1842.                  822.local-part.  In other cases the remaining
  1843.                  components should simply be encoded as a 822.local-part
  1844.                  using the EBNF.std-orname syntax.  Where registered
  1845.                  domain defined types exist, the DD. syntax should not
  1846.                  be used.
  1847.  
  1848.             4.   If this step is reached for an 822-P1 recipient, then
  1849.                  the address is invalid.  For other addresses, if the
  1850.                  derived 822.local-part can only be encoded by use of
  1851.                  822.quoted-string, the gateway may optionally use the
  1852.                  ASCII to 822.local-part mapping defined in Appendix A,
  1853.                  dependent on the mail protocols of the networks being
  1854.                  relayed to.  Use of this encoding is discouraged.
  1855.  
  1856.    4.3.  Repeated Mappings
  1857.  
  1858.       The mappings defined are symmetrical across a single gateway,
  1859.       except in certain pathological cases (see chapter 3).  However, it
  1860.       is always possible to specify any valid address across a gateway.
  1861.       This symmetry is particularly useful in cases of (mail exploder
  1862.       type) distribution list expansion.  For example, an X.400 user
  1863.       sends to a list on an RFC 822 system which he belongs to.  The
  1864.       received message will have the originator and any 3rd party X.400
  1865.       O/R names in correct format (rather than doubly encoded).  In
  1866.       cases (X.400 or RFC 822) where there is common agreement on
  1867.       gateway identification, then this will apply to multiple gateways.
  1868.  
  1869.       However, the syntax may be used to source route.
  1870.  
  1871.       For example:  X.400 -> RFC 822  -> X.400
  1872.  
  1873.          C               = "UK"
  1874.          ADMD            = "BT"
  1875.          PRMD            = "AC"
  1876.          "JNT-Mail"      = "/PN=Duval/DD.Title=Manager/(a)FR.PTT.Inria"
  1877.  
  1878.  
  1879.  
  1880. Kille                                                          [Page 33]
  1881.  
  1882.  
  1883.  
  1884. RFC 987                                                        June 1986
  1885. Mapping between X.400 and RFC 822
  1886.  
  1887.  
  1888.          This will be sent to an arbitrary UK Academic Community gateway
  1889.          by X.400.  Then by JNT Mail to another gateway determined by
  1890.          the domain FR.PTT.Inria.  This will then derive the X.400 O/R
  1891.          Name:
  1892.  
  1893.             C               = "FR"
  1894.             ADMD            = "PTT"
  1895.             PRMD            = "Inria"
  1896.             PN.S            = "Duval"
  1897.             "Title"         = "Manager"
  1898.  
  1899.       Similarly:  RFC 822 -> X.400 -> RFC 822
  1900.  
  1901.          "/C=UK/ADMD=BT/PRMD=AC/RFC-822=jj(a)seismo.css.gov/"
  1902.                                                      @monet.berkeley.edu
  1903.  
  1904.          /C=UK/ADMD=BT/PRMD=AC/RFC-822=jj#l#a#r#seismo.css.gov/
  1905.                                                      @monet.berkeley.edu
  1906.  
  1907.          The second case uses the Appendix A encoding to avoid
  1908.          822.quoted-text. This will be sent to monet.berkeley.edu by
  1909.          RFC 822, then to the AC PRMD by X.400, and then to
  1910.          jj@seismo.css.gov by RFC 822.
  1911.  
  1912.    4.4.  The full P1 / 822-P1 mapping
  1913.  
  1914.       There are two basic mappings at the P1 level:
  1915.  
  1916.          1.   822-P1 return address <-> P1.UMPDUEnvelope.originator
  1917.  
  1918.          2.   822-P1 recipient <-> P1.RecipientInfo
  1919.  
  1920.       822-P1 recipients and return addresses are encoded as
  1921.       EBNF.822-address.  As P1.UMPDUEnvelope.originator is encoded as
  1922.       P1.ORName, mapping 1) has already been specified.
  1923.       P1.RecipientInfo contains a P1.ORName and additional information.
  1924.       The handling of this additional information is now specified.
  1925.  
  1926.       4.4.1.  RFC 822 -> X.400
  1927.  
  1928.          The following default settings should be made for each
  1929.          component of P1.RecipientInfo.
  1930.  
  1931.             P1.ExtensionIdentifier
  1932.  
  1933.                This can be set systematically by the X.400 system.
  1934.  
  1935.  
  1936.  
  1937. Kille                                                          [Page 34]
  1938.  
  1939.  
  1940.  
  1941. RFC 987                                                        June 1986
  1942. Mapping between X.400 and RFC 822
  1943.  
  1944.  
  1945.             P1.RecipientInfo.perRecipientFlag
  1946.  
  1947.                Responsibility Flag should be set.  Report Request should
  1948.                be set according to content return policy, as discussed
  1949.                in section 5.3. User Report Request should be set to
  1950.                Basic.
  1951.  
  1952.             P1.ExplicitConversion
  1953.  
  1954.                This optional component should be omitted.
  1955.  
  1956.       4.4.2.  X.400 -> RFC 822
  1957.  
  1958.          The mapping only takes place in cases where
  1959.          P1.RecipientInfo.perRecipientFlag Responsibility Flag is set.
  1960.          The following treatment should be given to the other
  1961.          P1.RecipientInfo components.
  1962.  
  1963.             P1.ExtensionIdentifier
  1964.  
  1965.                Not used.
  1966.  
  1967.             P1.RecipientInfo.perRecipientFlag
  1968.  
  1969.                If ReportRequest is Confirmed or Audit-and-Confirmed then
  1970.                a delivery report indicating success should be sent by
  1971.                the gateway. This report should use each
  1972.                P1.ReportedRecipientInfo.SupplementaryInformation to
  1973.                indicate the identity of the gateway, and the nature of
  1974.                the report (i.e. only as far as the gateway).  Failures
  1975.                will be handled by returning RFC 822 messages, and so
  1976.                User Report Request set to No report is ignored.
  1977.  
  1978.             P1.ExplicitConversion
  1979.  
  1980.                If present, the O/R name should be rejected, unless the
  1981.                requested conversion can be achieved.  None of the
  1982.                currently recognised values of this parameter are
  1983.                appropriate to a gateway using this specification.
  1984.  
  1985.  
  1986.  
  1987.  
  1988.  
  1989.  
  1990.  
  1991.  
  1992.  
  1993.  
  1994. Kille                                                          [Page 35]
  1995.  
  1996.  
  1997.  
  1998. RFC 987                                                        June 1986
  1999. Mapping between X.400 and RFC 822
  2000.  
  2001.  
  2002.    4.5.  The full P2 / RFC 822 mapping
  2003.  
  2004.       All RFC 822 addresses are assumed to use the 822.mailbox syntax.
  2005.       This should include all 822.comments associated with the lexical
  2006.       tokens of the 822.mailbox.  All P2.ORNames are encoded within the
  2007.       syntax P2.ORDescriptor, or P2.Recipient (or within Message IDs).
  2008.       An asymmetrical mapping is defined between these components.
  2009.  
  2010.       4.5.1.  RFC 822 -> X.400
  2011.  
  2012.          The following sequence is followed.
  2013.  
  2014.             1.   Take the address, and extract an EBNF.822-address.
  2015.                  This can be derived trivially from either the
  2016.                  822.addr-spec or 822.route-addr syntax.  This is mapped
  2017.                  to P2.ORName as described above.
  2018.  
  2019.             2.   A string should be built consisting of (if present):
  2020.  
  2021.                -    The 822.phrase component if it is a 822.phrase
  2022.                     822.route-addr construct.
  2023.  
  2024.                -    Any 822.comments, in order, retaining the
  2025.                     parentheses.
  2026.  
  2027.                   This string should then be encoded into T.61 (as
  2028.                   described in chapter 3).  If the string is not null,
  2029.                   it should be assigned to P2.ORDescriptor.freeformName.
  2030.  
  2031.             3.   P2.ORDescriptor.telephoneNumber should be omitted.
  2032.  
  2033.             4.   In cases of converting to P2.Recipient,
  2034.                  P2.Recipient.replyRequest and
  2035.                  P2.Recipient.reportRequest should be omitted.
  2036.  
  2037.          If the 822.group construct is present, each included
  2038.          822.mailbox should be encoded as above.  The 822.group should
  2039.          be mapped to T.61, and a P2.ORDesciptor with only a
  2040.          freeformName component built from it.
  2041.  
  2042.       4.5.2.  X.400 -> RFC 822
  2043.  
  2044.          In the basic case, where P2.ORName is present, proceed as
  2045.          follows.
  2046.  
  2047.             1.   Encode P2.ORName as EBNF.822-address.
  2048.  
  2049.  
  2050.  
  2051. Kille                                                          [Page 36]
  2052.  
  2053.  
  2054.  
  2055. RFC 987                                                        June 1986
  2056. Mapping between X.400 and RFC 822
  2057.  
  2058.  
  2059.             2a.  If P2.ORDescriptor.freeformName is present, convert it
  2060.                  to ASCII (chapter 3), and use use this as the
  2061.                  822.phrase component of 822.mailbox using the
  2062.                  822.phrase 822.route-addr construct.
  2063.  
  2064.             2b.  If P2.ORDescriptor.freeformName is absent, if
  2065.                  EBNF.822-address is parsed as 822.addr-spec use this as
  2066.                  the encoding of 822.mailbox. If EBNF.822-address is
  2067.                  parsed as 822.route 822.addr-spec, then a 822.phrase
  2068.                  taken from 822.local-part should be added.
  2069.  
  2070.             3.   If P2.ORDescriptor.telephoneNumber is present, this
  2071.                  should be placed in a trailing 822.comment.
  2072.  
  2073.             4.   If P2.Recipient.reportRequest has the
  2074.                  receiptNotification bit set, then an 822.comment
  2075.                  "(Receipt Notification Requested)" should be appended
  2076.                  to the address.  The effort of correlating P1 and P2
  2077.                  information is too great to justify the gateway sending
  2078.                  Receipt Notifications.
  2079.  
  2080.             5.   If P2.Recipient.replyRequest is present, an 822.comment
  2081.                  "(Reply requested)" or "(Reply not requested)" should
  2082.                  be appended to the address, dependent on its value.
  2083.  
  2084.          If P2.ORName is absent, P2.ORDescriptor.freeformName should be
  2085.          converted to ASCII, and used with the RFC 822 822.group syntax:
  2086.  
  2087.             freeformname ":" ";"
  2088.  
  2089.          Steps 3-5 should then be followed.
  2090.  
  2091.    4.6.  Message IDs
  2092.  
  2093.       There is a need to map both ways between 822.msg-id and
  2094.       P2.IPMessageID.  A mapping is defined which is symmetrical for
  2095.       non-pathological cases.  The mapping allows for the fact that
  2096.       P2.IPMessageID.PrintableString is mandatory for the Cen/Cenelec
  2097.       profile.  This allows for good things to happen when messages pass
  2098.       multiple times across the X.400/RFC 822 boundary.  A mapping
  2099.       between 822.msg-id and P1.MPDUIdentifier is defined.  This allows
  2100.       for X.400 error messages to reference an RFC 822 ID, which is
  2101.       preferable to a gateway generated ID.
  2102.  
  2103.  
  2104.  
  2105.  
  2106.  
  2107.  
  2108. Kille                                                          [Page 37]
  2109.  
  2110.  
  2111.  
  2112. RFC 987                                                        June 1986
  2113. Mapping between X.400 and RFC 822
  2114.  
  2115.  
  2116.       4.6.1.  P2.IPMessageID -> 822.msg-id
  2117.  
  2118.          P2.IPMessageID.ORName is used to generate an 822.addr-spec, as
  2119.          defined above.  P2.IPMessageID.PrintableString is mapped to
  2120.          ASCII, as defined in chapter 3.  This string (if it is present
  2121.          and if the value is not "RFC-822") is appended to the front of
  2122.          the 822.local-part of the 822.msg-id, with "*" as a separator.
  2123.          If no ORName is present, an 822.msg-id of the form
  2124.          "PrintableString*@gateway-domain" is generated.
  2125.  
  2126.       4.6.2.  822.msg-id -> P2.IPMessageID
  2127.  
  2128.          822.local-part is parsed as:
  2129.  
  2130.             [ printablestring "*" ] real-local-part
  2131.  
  2132.          If EBNF.printablestring is found, it is mapped to
  2133.          PrintableString, and used as P2.IPMessageID.PrintableString.
  2134.          Otherwise
  2135.          P2.IPMessageID.PrintableString is set to "RFC-822".  This
  2136.          arbitrary value allows for conformance to Cen/Cenelec.  If
  2137.          EBNF.real-local-part is not present, no P2.IPMessageID.ORName
  2138.          is generated.  Otherwise,  822.local-part is replaced with
  2139.          EBNF.real-local-part, and 822.addr-spec is mapped to
  2140.          P2.IPMessageID.ORName as defined above.
  2141.  
  2142.       4.6.3.  822.msg-id -> P1.MPDUIdentifier
  2143.  
  2144.          P1.CountryName is assigned to "", P1.AdministrationDomainName
  2145.          to 822.domain (from 822.msg-id) and P1.MPDUIdentifier.IA5String
  2146.          to 822.local-part (from 822.msg-id).
  2147.  
  2148.       4.6.4.  P1.MPDUIdentifier -> 822.msg-id
  2149.  
  2150.          822.local-part is set to P1.MPDUIdentifier.IA5String, with any
  2151.          CRLF mapped to SPACE.  If P1.CountryName is "", 822.domain is
  2152.          set to P1.AdministrationDomainName; Otherwise to
  2153.          P1.AdministrationDomainName ".." P1.CountryName.  If there are
  2154.          any specials,  the domain literal encoding should be used.
  2155.  
  2156.  
  2157.  
  2158.  
  2159.  
  2160.  
  2161.  
  2162.  
  2163.  
  2164.  
  2165. Kille                                                          [Page 38]
  2166.  
  2167.  
  2168.  
  2169. RFC 987                                                        June 1986
  2170. Mapping between X.400 and RFC 822
  2171.  
  2172.  
  2173. Chapter 5 -- Protocol Elements
  2174.  
  2175.    This chapter gives detailed mappings for the functions outlined in
  2176.    chapters 1 and 2.  It makes extensive use of the notations and
  2177.    mappings defined in chapters 3 and 4.  This chapter is structured as
  2178.    follows:
  2179.  
  2180.       5.1. Basic RFC 822 -> X.400 mappings
  2181.  
  2182.       5.2. A definition of some new RFC 822 elements, and their mapping
  2183.            to X.400.
  2184.  
  2185.       5.3  Some special handling associated with Return of Contents.
  2186.  
  2187.       5.4. X.400 -> RFC 822
  2188.  
  2189.    5.1.  RFC 822 -> X.400
  2190.  
  2191.       First, the basic functions of an 822-P1 protocol should be mapped
  2192.       as follows:
  2193.  
  2194.          822-P1 Originator
  2195.  
  2196.             Mapped to P1.UMPDUEnvelope.originator (see chapter 4).
  2197.  
  2198.          822-P1 Recipient
  2199.  
  2200.             Mapped to P1.RecipientInfo (see chapter 4).
  2201.  
  2202.       The RFC 822 headers are used to generate both a P1.UMPDUEnvelope
  2203.       and a P2.Heading.  The IP Message will have either one or two
  2204.       P2.BodyParts which will be type P2.IA5Text with no
  2205.       P2.IA5Text.repertoire component. The last P2.BodyPart will contain
  2206.       the RFC 822 message body.  If there are any RFC 822 headers which
  2207.       indicate mapping into the P2.BodyPart, then two P2.BodyParts are
  2208.       generated.  If a revised version of P2 allowed for extensible
  2209.       header specification, this would be seen as a preferable mapping.
  2210.       The first body part will start with the line:
  2211.  
  2212.          RFC-822-Headers:
  2213.  
  2214.       The rest of this body part will contain all of the headers not
  2215.       otherwise mapped (both 822.field-name and 822.field-body).  The
  2216.       order of any such headers should be preserved.  Similarly,
  2217.       ordering within P2.Heading and P1.UMPDUEnvelope should reflect
  2218.       ordering within the RFC 822 header.  No P1 or P2 optional fields
  2219.       are generated unless specified.
  2220.  
  2221.  
  2222. Kille                                                          [Page 39]
  2223.  
  2224.  
  2225.  
  2226. RFC 987                                                        June 1986
  2227. Mapping between X.400 and RFC 822
  2228.  
  2229.  
  2230.       A pro-forma X.400 message is now specified.  Some of these
  2231.       defaults may be changed by the values in the RFC 822 message being
  2232.       mapped.  The mandatory P1 and P2 components have the following
  2233.       defaults.
  2234.  
  2235.          P1.MPDUIdentifier
  2236.  
  2237.             The default should be unique value generated by the gateway.
  2238.  
  2239.          P1.OriginatorORName
  2240.  
  2241.             Always generated from 822-P1.
  2242.  
  2243.          P1.ContentType
  2244.  
  2245.             P1.ContentType.p2
  2246.  
  2247.          P1.RecipientInfo
  2248.  
  2249.             These will always be supplied from 822-P1.
  2250.  
  2251.          P1.Trace
  2252.  
  2253.             The last P1.TraceInformation component is generated such
  2254.             that: P1.TraceInformation.GlobalDomainIdentifier is set to
  2255.             the local vaglue.  P1.DomainSuppliedInfo.action is set to
  2256.             relayed. P1.DomainSuppliedInfo.arrival is set to the current
  2257.             time. P1.DomainSuppliedInfo.previous may be set if there is
  2258.             anything sensible to set it to.
  2259.  
  2260.          P2.IPMessageID
  2261.  
  2262.             The default should be a unique value generated by the
  2263.             gateway.
  2264.  
  2265.       The following optional parameters should be set:
  2266.  
  2267.          P1.PerMessageFlag
  2268.  
  2269.             The P1.PerMessageFlag.contentReturnRequest bit should be set
  2270.             according to the discussion in section 5.3.  The
  2271.             P1.PerMessageFlag.alternateRecipientAllowed bit should be
  2272.             set, as it seems desirable to maximise opportunity for
  2273.             (reliable) delivery.
  2274.  
  2275.  
  2276.  
  2277.  
  2278.  
  2279. Kille                                                          [Page 40]
  2280.  
  2281.  
  2282.  
  2283. RFC 987                                                        June 1986
  2284. Mapping between X.400 and RFC 822
  2285.  
  2286.  
  2287.       The RFC 822 headings should be mapped as follows:
  2288.  
  2289.          Received:
  2290.  
  2291.             Fudged onto P1.TraceInformation (try not to grimace too
  2292.             much). P1.DomainSuppliedInfo.action is set to relayed.
  2293.             P1.DomainSuppliedInfo.arrival is set to the date-time
  2294.             component P1.TraceInformation.GlobalDomainIdentifier has
  2295.             P1.CountryName as a null string, and
  2296.             P1..AdministrationDomainName as the domain of the receiving
  2297.             host (if present - null string if not).
  2298.             P1.DomainSuppliedInfo.previous has P1.CountryName as a null
  2299.             string, and P1.AdministrationDomainName has the domain of
  2300.             the sending host with all other information enclosed in
  2301.             round parentheses.  The encoding of ASCII to PrintableString
  2302.             (chapter 3) should be used if needed.  For example:
  2303.  
  2304.                Received: from 44e.cs.ucl.ac.uk by vax2.Cs.Ucl.AC.UK
  2305.                               with SMTP  id a002110; 18 Dec 85 10:40 GMT
  2306.  
  2307.                   maps to -
  2308.  
  2309.                   P1.GlobalDomainIdentifier
  2310.                      CountryName                  = ""
  2311.                      AdministrationDomainName     = "vax2.Cs.Ucl.AC.UK"
  2312.                   P1.DomainSuppliedInfo
  2313.                      arrival                      = 18 Dec 85 10:40 GMT
  2314.                      action                       = relayed
  2315.                      previous
  2316.                         CountryName               = ""
  2317.                         AdministrationDomainName  =
  2318.                                "44e.cs.ucl.ac.uk (with SMTP id a002110)"
  2319.  
  2320.          Date:
  2321.  
  2322.             This is used to set the first component of
  2323.             P1.TraceInformation. The mandatory components are set as
  2324.             follows:
  2325.  
  2326.                P1.GlobalDomainIdentifier
  2327.                   CountryName                  = ""
  2328.                   AdministrationDomainName     = ""
  2329.                P1.DomainSuppliedInfo
  2330.                   arrival                      = time derived from Date:
  2331.                   action                       = relayed
  2332.  
  2333.             No optional fields are used in the trace.
  2334.  
  2335.  
  2336. Kille                                                          [Page 41]
  2337.  
  2338.  
  2339.  
  2340. RFC 987                                                        June 1986
  2341. Mapping between X.400 and RFC 822
  2342.  
  2343.  
  2344.          Message-Id:
  2345.  
  2346.             Mapped to P2.IPMessageID.  If the RFC 822 message does not
  2347.             contain a P1-Message-ID: field, the Message-Id: field is
  2348.             also mapped to P1.MPDUIdentifier.  For these, and all other
  2349.             fields containing msg-id the mappings of chapter 4 are used
  2350.             for each msg-id.
  2351.  
  2352.          From:
  2353.  
  2354.             If Sender: is present, this is mapped to
  2355.             P2.AuthorisingUsers.  If not, it is mapped to P2.Originator.
  2356.             For this, and other components containing addresses, the
  2357.             mappings of chapter 4 are used for each address.
  2358.  
  2359.          Sender:
  2360.  
  2361.             Mapped to P2.Originator.
  2362.  
  2363.          Reply-To:
  2364.  
  2365.             Mapped to P2.Heading.replyToUsers.
  2366.  
  2367.          To:
  2368.  
  2369.             Mapped to P2.Heading.primaryRecipients
  2370.  
  2371.          Cc:
  2372.  
  2373.             Mapped to P2.Heading.copyRecipients.
  2374.  
  2375.          Bcc:
  2376.  
  2377.             Mapped to P2.Heading.blindCopyRecipients.
  2378.  
  2379.          In-Reply-To:
  2380.  
  2381.             Mapped to P2.Heading.inReplyTo for the first (if any)
  2382.             822.msg-id component.  If the field contains an 822.phrase
  2383.             component, or there are multiple 822.msg-id components, the
  2384.             ENTIRE field is passed in the P2.BodyPart.
  2385.  
  2386.          References:
  2387.  
  2388.             Mapped to P2.Heading.crossReferences.
  2389.  
  2390.  
  2391.  
  2392.  
  2393. Kille                                                          [Page 42]
  2394.  
  2395.  
  2396.  
  2397. RFC 987                                                        June 1986
  2398. Mapping between X.400 and RFC 822
  2399.  
  2400.  
  2401.          Keywords:
  2402.  
  2403.             Passed in the P2.BodyPart.
  2404.  
  2405.          Subject:
  2406.  
  2407.             Mapped to P2.Heading.subject.  The field-body uses the
  2408.             mapping referenced in chapter 3 from ASCII to T.61.
  2409.  
  2410.          Comments:
  2411.  
  2412.             Passed in the P2.BodyPart.
  2413.  
  2414.          Encrypted:
  2415.  
  2416.             Passed in the P2.BodyPart.
  2417.  
  2418.          Resent-*
  2419.  
  2420.             Passed in the P2..BodyPart <8>.
  2421.  
  2422.          Other Fields
  2423.  
  2424.             In particular X-* fields, and "illegal" fields in common
  2425.             usage (e.g. "Fruit-of-the-day:") are passed in the
  2426.             P2.BodyPart.  The same treatment should be applied to
  2427.             RFC 822 fields where the content of the field does not
  2428.             conform to RFC 822 (e.g. a Date: field with unparsable
  2429.             syntax).
  2430.  
  2431.    5.2.  Extended RFC 822 Elements -> X.400
  2432.  
  2433.       First an EBNF definition of a number of extended fields is given,
  2434.       and then a mapping to X.400 is defined.  In most cases, the
  2435.       RFC 822 syntax is defined to make this mapping very
  2436.       straightforward, and so no detailed explanation of the mapping is
  2437.       needed.
  2438.  
  2439.          extended-field  = "P1-Message-ID" ":" p1-msg-id
  2440.                          / "X400-Trace" ":" x400-trace
  2441.                          / "Original-Encoded-Information-Types"
  2442.                             ":"encoded-info
  2443.                          / "P1-Content-Type" ":" p1-content-type
  2444.                          / "UA-Content-ID" ":" printablestring
  2445.                          / "Priority" ":" priority
  2446.                          / "P1-Recipient" : 1 mailbox
  2447.                          / "Deferred-Delivery" ":" date-time
  2448.  
  2449.  
  2450. Kille                                                          [Page 43]
  2451.  
  2452.  
  2453.  
  2454. RFC 987                                                        June 1986
  2455. Mapping between X.400 and RFC 822
  2456.  
  2457.  
  2458.                          / "Bilateral-Info" ":" bilateral-info
  2459.                          / "Obsoletes" ":" 1 msg-id
  2460.                          / "Expiry-Date" ":" date-time
  2461.                          / "Reply-By" ":" date-time
  2462.                          / "Importance" ":" importance
  2463.                          / "Sensitivity" ":" sensitivity
  2464.                          / "Autoforwarded" ":" boolean
  2465.  
  2466.          p1-msg-id       = global-id ";" *text
  2467.  
  2468.          p1-content-type = "P2" / atom
  2469.  
  2470.          x400-trace      = global-id ";"
  2471.                          "arrival" date-time
  2472.                          [ "deferred" date-time ]
  2473.                          [ "action" action ]
  2474.                          [ "converted" "(" encoded-info ")" ]
  2475.                          [ "previous" global-id ]
  2476.  
  2477.          action          = "Relayed" / "Rerouted" / escape
  2478.  
  2479.          global-id       = c "*" admd [ "*" prmd ]
  2480.  
  2481.          encoded-info    = 1 encoded-type
  2482.  
  2483.          encoded-type    = "Undefined"           ; undefined (0)
  2484.                          / "Telex"               ; tLX (1)
  2485.                          / "IA5-Text"            ; iA5Text (2)
  2486.                          / "G3-Fax"              ; g3Fax (3)
  2487.                          / "TIF0"                ; tIF0 (4)
  2488.                          / "Teletex"             ; tTX (5)
  2489.                          / "Videotex"            ; videotex (6)
  2490.                          / "Voice"               ; voice (7)
  2491.                          / "SFD"                 ; sFD (8)
  2492.                          / "TIF1"                ; tIF1 (9)
  2493.                          / escape
  2494.  
  2495.          priority        = "normal" / "non-urgent" / "urgent" / escape
  2496.  
  2497.          bilateral-info  = c "*" admd "*" *text
  2498.  
  2499.          importance      = "low" / "normal" / "high" / escape
  2500.  
  2501.          sensitivity     = "Personal" / "Private"
  2502.                          / "Company-Confidential" / escape
  2503.  
  2504.          escape          = 1*DIGIT
  2505.  
  2506.  
  2507. Kille                                                          [Page 44]
  2508.  
  2509.  
  2510.  
  2511. RFC 987                                                        June 1986
  2512. Mapping between X.400 and RFC 822
  2513.  
  2514.  
  2515.       With the exception of "Bilateral-Info:" and "X400-Trace:", there
  2516.       must be no more than one of each of these fields in an RFC 822
  2517.       header.  Any field beginning with the String "Autoforwarded-" is
  2518.       valid if the field would be syntactically valid with this string
  2519.       removed.
  2520.  
  2521.       The mappings to X.400 are as follows:
  2522.  
  2523.          P1-Message-ID:
  2524.  
  2525.             Mapped to P1.UMPDUEnvelope.MPDUIdentifier.  This take
  2526.             precedence over any value derived from Message-ID:.
  2527.  
  2528.          X400-Trace:
  2529.  
  2530.             Mapped to the next component of
  2531.             P1.UMPDUEnvelope.Traceinformation.  Care should be taken to
  2532.             preserve order.  If one or more of these mappings is made,
  2533.             then a trace component should NOT be generated from the
  2534.             Date: field which should be redundant.  This is because the
  2535.             message has previously come from X.400, and the Date:
  2536.             information will be redundant.  Note that all trace
  2537.             information (Received: and "X400-Trace:") in the RFC 822
  2538.             message will be in strict order, with the most recent at the
  2539.             top.  This order should be preserved in the mapping.
  2540.  
  2541.          Original-Encoded-Information-Types:
  2542.  
  2543.             This is used to set P1.UMPDUEnvelope.original.
  2544.             P1.EncodedInformationTypes.[0] has bits set according to
  2545.             each of the encoded-info components in this field.  Any
  2546.             escape values should not be encoded.
  2547.  
  2548.          P1-Content-Type:
  2549.  
  2550.             If the value is anything other than "P2", the mapping should
  2551.             not be performed (unless the new value has some semantics to
  2552.             the gateway).
  2553.  
  2554.          UA-Content-ID:
  2555.  
  2556.             Mapped to P1.UMPDUEnvelope.UAContentID.
  2557.  
  2558.          Priority:
  2559.  
  2560.             Mapped to P1.UMPDUEnvelope.Priority.  An escape value should
  2561.             be encoded as P1.Priority.normal.
  2562.  
  2563.  
  2564. Kille                                                          [Page 45]
  2565.  
  2566.  
  2567.  
  2568. RFC 987                                                        June 1986
  2569. Mapping between X.400 and RFC 822
  2570.  
  2571.  
  2572.          P1-Recipient:
  2573.  
  2574.             If this field is set, the
  2575.             P1.PerMessageFlag.discloseRecipients bit should be set.  Any
  2576.             of the addresses here which do not correspond to 822-P1
  2577.             recipients should be added to the P1 recipient list, with
  2578.             the responsibility bit turned off.
  2579.  
  2580.          Deferred-Delivery:
  2581.  
  2582.             Mapped to P1.UMPDUEnvelope.deferredDelivery.  Note that the
  2583.             value of this field should always be in the past, as this
  2584.             field should only be present in messages which have come
  2585.             originally from X.400.  Thus there should be no implied
  2586.             action.  See also the comments on the reverse mapping.
  2587.  
  2588.          Bilateral-Info:
  2589.  
  2590.             No attempt is made to reconvert this information back to
  2591.             X.400.
  2592.  
  2593.          Obsoletes:
  2594.  
  2595.             Mapped to P2.Heading.obsoletes.
  2596.  
  2597.          Expiry-Date:
  2598.  
  2599.             Mapped to P2.Heading.expiryDate.
  2600.  
  2601.          Reply-By:
  2602.  
  2603.             Mapped to P2.Heading.replyBy.
  2604.  
  2605.          Importance:
  2606.  
  2607.             Mapped to P2.Heading.importance.  An escape value should be
  2608.             encoded as P2.Heading.importance.normal.
  2609.  
  2610.          Sensitivity:
  2611.  
  2612.             Mapped to P2.Heading.sensitivity.  An escape value should be
  2613.             encoded as P2.Heading.sensitivity.normal.
  2614.  
  2615.          Autoforwarded:
  2616.  
  2617.             If this field is present and the value is "TRUE", there will
  2618.             be zero or more field names beginning "Autoforwarded-".
  2619.  
  2620.  
  2621. Kille                                                          [Page 46]
  2622.  
  2623.  
  2624.  
  2625. RFC 987                                                        June 1986
  2626. Mapping between X.400 and RFC 822
  2627.  
  2628.  
  2629.             These should be taken, and the string "Autoforwarded-"
  2630.             stripped.  These fields, in conjunction with the 822-P1
  2631.             information should be used to build an IP Message.  Any
  2632.             implied actions should be taken. P2.Heading.autoforwarded is
  2633.             set in this message.  The other RFC 822 fields are used to
  2634.             build another IP Message, which is used as the single body
  2635.             part of the first message.  This mechanism does not nest.
  2636.  
  2637.    5.3.  Return of Contents
  2638.  
  2639.       It is not clear how widely supported X.400 return of contents
  2640.       service will be.  However, profiling work suggests that most
  2641.       systems will not support this service.  As this service is
  2642.       expected in the RFC 822 world, two approaches are specified (it is
  2643.       not so necessary in the X.400 world, as delivery reports are
  2644.       distinguished from messages).  The choice will depend on the
  2645.       service level of the X.400 community being serviced by the
  2646.       gateway.
  2647.  
  2648.       In environments where return of contents is widely supported, the
  2649.       P1.PerMessageFlag content return request bit will be set, and the
  2650.       Report Request bit in P1.PerRecipientFlag will be set to
  2651.       Confirmed, for every message passing from RFC 822 -> X.400.  The
  2652.       content return service can then be passed back to the end
  2653.       (RFC 822) user in a straightforward manner.
  2654.  
  2655.       In environments where return of contents is not widely supported,
  2656.       a gateway must make special provisions to handle return of
  2657.       contents.  For every message passing from RFC 822 -> X.400, the
  2658.       P1.PerMessageFlag content return request bit will be set, and the
  2659.       Report Request bit in P1.PerRecipientFlag will be set to
  2660.       Confirmed.  When the delivery report comes back, the gateway can
  2661.       note that the message has been delivered to the recipient(s) in
  2662.       question.  If a non-delivery report is received, a meaningful
  2663.       report (containing some or all of the original message) can be
  2664.       sent to the 822-P1 originator.  If no report is received for a
  2665.       recipient, a (timeout) failure notice should be sent to the 822-P1
  2666.       originator.  The gateway may retransmit the X.400 message if it
  2667.       wishes.  Delivery confirmations should only be sent back to the
  2668.       822-P1 originator if the P1.PerRecipientFlag User Report Request
  2669.       bit is set to Confirmed.
  2670.  
  2671.  
  2672.  
  2673.  
  2674.  
  2675.  
  2676.  
  2677.  
  2678. Kille                                                          [Page 47]
  2679.  
  2680.  
  2681.  
  2682. RFC 987                                                        June 1986
  2683. Mapping between X.400 and RFC 822
  2684.  
  2685.  
  2686.    5.4.  X.400 -> RFC 822
  2687.  
  2688.       5.4.1.  General
  2689.  
  2690.          This section describes how to build a pro-forma message, and
  2691.          then explains how these defaults may be overridden.  It should
  2692.          be noted that RFC 822 folding of headers should be used in an
  2693.          appropriate manner.
  2694.  
  2695.       5.4.2.  Service MPDU
  2696.  
  2697.          5.4.2.1.  Probe
  2698.  
  2699.             Any P1.ProbeMPDU should be serviced by the gateway, as there
  2700.             is no equivalent RFC 822 functionality.  The value of the
  2701.             reply is dependent on whether the gateway could service a
  2702.             User MPDU with the values specified in the probe.  The reply
  2703.             should make use of P1.SupplementaryInformation to indicate
  2704.             that the probe was serviced by the gateway.
  2705.  
  2706.          5.4.2.2.  Delivery Report
  2707.  
  2708.             The 822-P1 components are constructed as follows:
  2709.  
  2710.                822-P1 Originator
  2711.  
  2712.                   This is set to an 822.addr-spec pointing to an
  2713.                   administrator at the gateway.
  2714.  
  2715.                822-P1 Recipient
  2716.  
  2717.                   The single recipient is constructed from
  2718.                   P1.DeliveryReportEnvelope.originator, using the
  2719.                   mappings of chapter 4.
  2720.  
  2721.             The mandatory RFC 822 headers for an RFC 822 pro-forma are
  2722.             constructed as follows:
  2723.  
  2724.                Date:
  2725.  
  2726.                   From the P1.DomainSuppliedInfo.arrival component of
  2727.                   the first P1.TraceInformation component.
  2728.  
  2729.                From:
  2730.  
  2731.                   This is set to the same as the 822-P1 originator.  An
  2732.  
  2733.  
  2734.  
  2735. Kille                                                          [Page 48]
  2736.  
  2737.  
  2738.  
  2739. RFC 987                                                        June 1986
  2740. Mapping between X.400 and RFC 822
  2741.  
  2742.  
  2743.                   appropriate phrase component may be added (e.g. giving
  2744.                   the name of the gateway).
  2745.  
  2746.                To:
  2747.  
  2748.                   The same as the 822-P1 recipient.
  2749.  
  2750.             A Subject: field should be added, which contains some
  2751.             appropriate words (e.g. "Delivery Report").
  2752.  
  2753.             The other two P1.DeliveryReportEnvelope parameters should be
  2754.             mapped as follows:
  2755.  
  2756.                P1.DeliveryReportEnvelope.report
  2757.  
  2758.                   This should be mapped to a P1-Message-Id: field.
  2759.  
  2760.                P1.DeliveryReportEnvelope.TraceInformation
  2761.  
  2762.                   Each component should be mapped to an "X400-Trace:"
  2763.                   field.  RFC 822 and X.400 ordering should be
  2764.                   maintained (see 5.3).
  2765.  
  2766.             The P1.DeliveryReportContent parameters should be mapped to
  2767.             a series of new RFC 822 headers.  These new headers are
  2768.             intended for processing in the RFC 822 world.  No attempt
  2769.             will be made to reverse the mappings.
  2770.  
  2771.                drc-field    = "Delivery-Report-Content-Original"
  2772.                            ":" msg-id
  2773.                  / "Delivery-Report-Content-Intermediate-Trace"
  2774.                            ":" x400-trace
  2775.                  / "Delivery-Report-Content-UA-Content-ID"
  2776.                            ":" printablestring
  2777.                  / "Delivery-Report-Content-Billing-Information"
  2778.                            ":" *text
  2779.                  / "Delivery-Report-Content-Reported-Recipient-Info"
  2780.                            ":" drc-info
  2781.  
  2782.                drc-info     = mailbox ";"
  2783.                             last-trace ";"
  2784.                             "ext" 1*DIGIT
  2785.                             "flags" 2DIGIT
  2786.                             [ "intended" mailbox ] ";"
  2787.                             [ "info" printablestring ]
  2788.  
  2789.  
  2790.  
  2791.  
  2792. Kille                                                          [Page 49]
  2793.  
  2794.  
  2795.  
  2796. RFC 987                                                        June 1986
  2797. Mapping between X.400 and RFC 822
  2798.  
  2799.  
  2800.                last-trace   = drc-report ";"
  2801.                             date-time ";"
  2802.                             [ "converted" "(" encoded-info ")"
  2803.  
  2804.                drc-report   = "SUCCESS" drc-success
  2805.                             / "FAILURE" drc-failure
  2806.  
  2807.                drc-success  = date-time ";" 1*DIGIT
  2808.  
  2809.                drc-failure  = *text [ ";" *text ] ";"
  2810.  
  2811.             There may be multiple
  2812.             "Delivery-Report-Content-Intermediate-Trace:" and
  2813.             "Delivery-Report-Content-Reported-Recipient-Info:" fields.
  2814.             The msg-id for "Delivery-Report-Content-Original" is derived
  2815.             according to the mapping of chapter 4.  EBNF.drc-failure may
  2816.             use numeric values or textual explanation.  The latter is
  2817.             preferred.  All P1.DeliveryReportContent parameters are
  2818.             mapped to the corresponding component.  The order of
  2819.             "Delivery-Report-Content-Intermediate-Trace:" should have
  2820.             the most recently stamped one first.
  2821.  
  2822.             The body of the RFC 822 message should be a human readable
  2823.             description of the critical parts of the
  2824.             P1.DeliveryReportContent.  In particular, the failed
  2825.             recipients, and failure reason should be given.  Some or all
  2826.             of the original message should be included in the delivery
  2827.             report. The original message will be available at the
  2828.             gateway, as discussed in section 5.3.
  2829.  
  2830.       5.4.3.  User MPDU
  2831.  
  2832.          These elements are the basis for both Status Report and IP
  2833.          Message.
  2834.  
  2835.          The 822-P1 components are constructed as follows:
  2836.  
  2837.             822-P1 Originator
  2838.  
  2839.                This is derived from P1.UMPDUEnvelope.originator.
  2840.  
  2841.             822-P1 Recipient
  2842.  
  2843.                Each recipient is constructed from the P1.RecipientInfo,
  2844.                as described in chapter 4.  This describes actions as
  2845.                well as format mappings.
  2846.  
  2847.  
  2848.  
  2849. Kille                                                          [Page 50]
  2850.  
  2851.  
  2852.  
  2853. RFC 987                                                        June 1986
  2854. Mapping between X.400 and RFC 822
  2855.  
  2856.  
  2857.          The mandatory RFC 822 field pro-forma is derived as follows.
  2858.          In most cases where the P1.UMPDUContent is an IP Message, these
  2859.          defaults will be overridden:
  2860.  
  2861.             Date:
  2862.  
  2863.                From the P1.DomainSuppliedInfo.arrival component of the
  2864.                first P1.TraceInformation component.
  2865.  
  2866.             From:
  2867.  
  2868.                From the P1.UMPDUEnvelope.originator, as defined in
  2869.                chapter 4.
  2870.  
  2871.             To:
  2872.  
  2873.                This default is only required if the generated RFC 822
  2874.                message has no destination specification.  If
  2875.                P1.PerMessageFlag.discloseRecipients is set then it
  2876.                should contain the ORName in each P1.RecipientInfo
  2877.                component.  If it is not set, the it should be set to
  2878.                "To: No Recipients Specified : ;".
  2879.  
  2880.          The mappings, and any actions for each P1.UserMPDU element is
  2881.          now considered.
  2882.  
  2883.             P1.MPDUIdentifier
  2884.  
  2885.                Mapped to the extended RFC 822 field "P1-Message-ID:".
  2886.                Note that the sequence CRLF is mapped to SPACE, which
  2887.                makes the mapping irreversible for such cases.
  2888.  
  2889.             P1.UMPDUEnvelope.original
  2890.  
  2891.                Mapped to the extended RFC 822 field
  2892.                "Original-Encoded-Information-Types:".  If it contains
  2893.                only P2.IA5Text, the RFC 822 field may be omitted.
  2894.  
  2895.             P1.ContentType
  2896.  
  2897.                As this can currently only have one value, it is not
  2898.                mapped, on the basis that it is redundant.  If the field
  2899.                contains any value other than P2, then the UMPDU should
  2900.                be rejected.
  2901.  
  2902.  
  2903.  
  2904.  
  2905.  
  2906. Kille                                                          [Page 51]
  2907.  
  2908.  
  2909.  
  2910. RFC 987                                                        June 1986
  2911. Mapping between X.400 and RFC 822
  2912.  
  2913.  
  2914.             P1.UAContentID
  2915.  
  2916.                Mapped to the extended RFC 822 field "UA-Content-Id:".
  2917.  
  2918.             P1.Priority
  2919.  
  2920.                Mapped to the extended RFC 822 field "Priority:".
  2921.  
  2922.             P1.PerMesageFlag
  2923.  
  2924.                This has a number of components:
  2925.  
  2926.                   - discloseRecipients
  2927.  
  2928.                      If this bit is set, a "P1-Recipient:" field should
  2929.                      be generated, and contain each of the P1
  2930.                      recipients.
  2931.  
  2932.                   - conversionProhibited
  2933.  
  2934.                      If this bit is set, the message should be rejected
  2935.                      if it contains P2.BodyPart which is not P2.IA5Text
  2936.                      or P2.ForwardedIPMessage.
  2937.  
  2938.                   - alternateRecipientAllowed
  2939.  
  2940.                      The value of this bit is ignored.
  2941.  
  2942.                   - contentReturnRequest
  2943.  
  2944.                      The value of this bit is ignored.
  2945.  
  2946.             P1.UMPDUEnvelope.deferredDelivery
  2947.  
  2948.                This should be mapped to the extended RFC 822 field
  2949.                "Deferred-Delivery:".  X.400 profiles, and in particular
  2950.                the CEN/CENELEC profile [CEN/CENELEC/85a], specify that
  2951.                this element must be supported at the first MTA.  Thus,
  2952.                it is expected that the value of this element will always
  2953.                be in the past.  If it is not, the function may
  2954.                optionally be implemented by the gateway: that is, the
  2955.                gateway should hold the message until the time specified
  2956.                in the protocol element.  Thus the extended RFC 822 field
  2957.                is just for information.
  2958.  
  2959.  
  2960.  
  2961.  
  2962.  
  2963. Kille                                                          [Page 52]
  2964.  
  2965.  
  2966.  
  2967. RFC 987                                                        June 1986
  2968. Mapping between X.400 and RFC 822
  2969.  
  2970.  
  2971.             P1.PerDomainBilateralInformation
  2972.  
  2973.                Each component should be encoded in the extended RFC 822
  2974.                field "Bilateral-Info:".  P1.BilateralInfo should be
  2975.                mapped into ASCII in a manner appropriate to its
  2976.                contents.  This submapping is not reversible.
  2977.  
  2978.             P1.TraceInformation
  2979.  
  2980.                This should be mapped to "X400-Trace:", as for the
  2981.                delivery report.
  2982.  
  2983.       5.4.4.  Status Report
  2984.  
  2985.          The entire status report is mapped into the body of the RFC 822
  2986.          message, in the same manner as for a Delivery Report.  An
  2987.          appropriate "Subject:" field should be generated.  As status
  2988.          reports cannot be requested from the RFC 822 world, the mapping
  2989.          is not likely to be used a great deal.
  2990.  
  2991.       5.4.5.  IP Message
  2992.  
  2993.          The P1.UMPDUEnvelope pro-forma specification ensures all the
  2994.          822-P1 information, and a minimal (legal) RFC 822 message.  The
  2995.          mappings and actions for the P2.Heading components are now
  2996.          described.  Basically, these are interpreted as actions and/or
  2997.          mappings into RFC 822 fields. The following mappings are
  2998.          specified:
  2999.  
  3000.             P2.IPMessageID
  3001.  
  3002.                This is mapped to the field "Message-ID:", according to
  3003.                section 4.
  3004.  
  3005.             P2.Heading.originator
  3006.  
  3007.                If P2.Heading.authorisingUsers is present this is mapped
  3008.                to Sender:, if not to From:.
  3009.  
  3010.             P2.Heading.authorisingUsers
  3011.  
  3012.                Mapped to From:.
  3013.  
  3014.             P2.Heading.primaryRecipients
  3015.  
  3016.                Mapped to To:.
  3017.  
  3018.  
  3019.  
  3020. Kille                                                          [Page 53]
  3021.  
  3022.  
  3023.  
  3024. RFC 987                                                        June 1986
  3025. Mapping between X.400 and RFC 822
  3026.  
  3027.  
  3028.             P2.Heading.copyRecipients
  3029.  
  3030.                Mapped to Cc:.
  3031.  
  3032.             P2.Heading.blindCopyRecipients
  3033.  
  3034.                Mapped to Bcc:.
  3035.  
  3036.             P2.Heading.inReplyTo
  3037.  
  3038.                Mapped to In-Reply-To:.
  3039.  
  3040.             P2.Heading.obsoletes
  3041.  
  3042.                Mapped to the extended RFC 822 field "Obsoletes:"
  3043.  
  3044.             P2.Heading.crossReferences
  3045.  
  3046.                Mapped to References:.
  3047.  
  3048.             P2.Heading.subject
  3049.  
  3050.                Mapped to subject.  The contents are converted to ASCII
  3051.                (as defined in chapter 3).  Any CRLF are not mapped, but
  3052.                are used as points at which the subject field must be
  3053.                folded.  line.
  3054.  
  3055.             P2.Heading.expiryDate
  3056.  
  3057.                Mapped to the extended RFC 822 field "Expiry-Date:".
  3058.  
  3059.             P2.Heading.replyBy
  3060.  
  3061.                Mapped to the extended RFC 822 field "Reply-By:".
  3062.  
  3063.             P2.Heading.replyToUsers
  3064.  
  3065.                Mapped to Reply-To:.
  3066.  
  3067.             P2.Heading.importance
  3068.  
  3069.                Mapped to the extended RFC 822 field "Importance:".
  3070.  
  3071.             P2.Heading.sensitivity
  3072.  
  3073.                Mapped to the extended RFC 822 field "Sensitivity:".
  3074.  
  3075.  
  3076.  
  3077. Kille                                                          [Page 54]
  3078.  
  3079.  
  3080.  
  3081. RFC 987                                                        June 1986
  3082. Mapping between X.400 and RFC 822
  3083.  
  3084.  
  3085.             P2.Heading.autoforwarded
  3086.  
  3087.                If it is set to FALSE, it is simply mapped to the
  3088.                extended RFC 822 field "Autoforwarded:".  If this is set
  3089.                to TRUE, the P2.Body does not consist of a single
  3090.                P2.ForwardedIPMessage, then there is an X.400 error, and
  3091.                the message should be bounced.  Otherwise the following
  3092.                steps are taken.
  3093.  
  3094.                   1.  The mappings for all of the message, except the
  3095.                       body part are completed.
  3096.  
  3097.                   2.  Prepend each RFC 822 fieldname with the string
  3098.                       "Autoforwarded-". Mapped to the extended RFC 822
  3099.                       field "Autoforwarded:".
  3100.  
  3101.                   3.  Add the field "Autoforwarded:" with value TRUE.
  3102.  
  3103.                   4.  Convert the syntax of the P2.ForwardedIPMessage to
  3104.                       generate the remaining RFC 822 fields.
  3105.  
  3106.          The P2.Body is mapped into the RFC 822 message body.  Each
  3107.          P2.BodyPart is converted to ASCII.  If the P2.Body contains a
  3108.          P2.BodyPart not listed here, the entire message should be
  3109.          rejected.  If there are exactly two P2.IA5Text body parts, and
  3110.          the first line of the first is "RFC-822-Headers:", then the
  3111.          rest of this first body part should be treated as additional
  3112.          header information for the RFC 822 message.  If there is an
  3113.          "In-Reply-To:" field, this should be used to replace any
  3114.          generated In-Reply-To: field.
  3115.  
  3116.          In other cases of multiple P2.BodyPart, the mapping defined by
  3117.          Rose and Stefferud in [Rose85b], should be used to separate the
  3118.          P2.BodyParts in the single RFC 822 message body.
  3119.  
  3120.          Individual body parts are mapped as follows:
  3121.  
  3122.             P2.IA5Text
  3123.  
  3124.                The mapping is trivial.
  3125.  
  3126.             P2.TTX
  3127.  
  3128.                If any P1.Teletex.NonBasicParams are set, the message
  3129.                should be rejected.  Otherwise, it should be converted to
  3130.                ASCII according to chapter 3.
  3131.  
  3132.  
  3133.  
  3134. Kille                                                          [Page 55]
  3135.  
  3136.  
  3137.  
  3138. RFC 987                                                        June 1986
  3139. Mapping between X.400 and RFC 822
  3140.  
  3141.  
  3142.             P2.SFD
  3143.  
  3144.                An SFD should be converted to ASCII as if it was being
  3145.                rendered on an 79 column ASCII only VDU.  It seems likely
  3146.                that many gateways will not support this conversion.  In
  3147.                these cases, the message should be rejected.
  3148.  
  3149.             P2.ForwardedIPMessage
  3150.  
  3151.                The P2.ForwardedIPMessage.delivery and
  3152.                P2.ForwardedIPMessage.DeliveryInformation are
  3153.                discarded <9>.  The IM-UAPDU should have its syntax
  3154.                mapped (recursively) according to this gatewaying
  3155.                specification.  Clearly, it makes no sense to apply any
  3156.                of the actions defined here.
  3157.  
  3158.  
  3159.  
  3160.  
  3161.  
  3162.  
  3163.  
  3164.  
  3165.  
  3166.  
  3167.  
  3168.  
  3169.  
  3170.  
  3171.  
  3172.  
  3173.  
  3174.  
  3175.  
  3176.  
  3177.  
  3178.  
  3179.  
  3180.  
  3181.  
  3182.  
  3183.  
  3184.  
  3185.  
  3186.  
  3187.  
  3188.  
  3189.  
  3190.  
  3191. Kille                                                          [Page 56]
  3192.  
  3193.  
  3194.  
  3195. RFC 987                                                        June 1986
  3196. Mapping between X.400 and RFC 822
  3197.  
  3198.  
  3199. Appendix A -- Quoted String Encodings
  3200.  
  3201.    This Appendix describes a quoting mechanism which may be used to
  3202.    allow general interworking between RFC 822, and variants of RFC 822
  3203.    which do not support 822.quoted-string.  This is important, as the
  3204.    basic X.400 <-> RFC 822 mapping makes use of 822.quoted-string.
  3205.  
  3206.    1.  ASCII <-> 822.atom
  3207.  
  3208.       The following EBNF is specified.
  3209.  
  3210.          atom-encoded    = *( a-char / a-encoded-char )
  3211.          a-char          = <any CHAR except specials, SPACE,
  3212.                                  CTL, "_", and "#">
  3213.          a-encoded-char  = "_"                   ; (space)
  3214.                          / "#u#"                 ; (_)
  3215.                          / "#l#"                 ; <(>
  3216.                          / "#r#"                 ; <)>
  3217.                          / "#m#"                 ; (,)
  3218.                          / "#c#"                 ; (:)
  3219.                          / "#b#"                 ; (\)
  3220.                          / "#h#"                 ; (#)
  3221.                          / "#e#"                 ; ($=)
  3222.                          / "#s#"                 ; ($/)
  3223.                          / "#" 3DIGIT "#"
  3224.  
  3225.       NOTE: There are two encodings of double characters.  This is so
  3226.       that systems using this encoding, do not also need to know about
  3227.       the "$" quoting mechanism defined in chapter 4.
  3228.  
  3229.       The 822.3DIGIT in EBNF.a-encoded-char must have range 0-127
  3230.       (Decimal), and is interpreted in decimal as the corresponding
  3231.       ASCII character.  The choice of special abbreviations (as opposed
  3232.       to octal encoding) provided is based on the manner in which this
  3233.       mapping is most frequently used: encoding PrintableString
  3234.       components of O/R names as atom.  Therefore, there are special
  3235.       encodings for each of the PrintableString characters not in
  3236.       EBNF.a-char, except ".".  Space is given a single character
  3237.       encoding, due to its (expected) frequency of use, and backslash as
  3238.       the RFC 822 single quote character.
  3239.  
  3240.       To encode (ASCII -> atom): all EBNF.a-char are used directly and
  3241.       all other CHAR are encoded as EBNF.a-encoded-char.  To decode
  3242.       (822.atom -> ASCII): if 822.atom can be parsed as
  3243.       EBNF.encoded-atom reverse the previous mapping.  If it cannot be
  3244.       so parsed, map the characters directly.
  3245.  
  3246.  
  3247.  
  3248. Kille                                                          [Page 57]
  3249.  
  3250.  
  3251.  
  3252. RFC 987                                                        June 1986
  3253. Mapping between X.400 and RFC 822
  3254.  
  3255.  
  3256.    2.  822.local-part <-> ASCII
  3257.  
  3258.       A related transformation is for 822.local-part (or other element
  3259.       defined as '822.word ("." 822.word)') where not 822.quoted-text is
  3260.       used.  To encode (ASCII -> 822.local-part), all EBNF.a-char and
  3261.       "." are used directly and all other 822.CHAR are encoded as
  3262.       EBNF.a-encoded-char.  To decode (822.local-part -> ASCII), first
  3263.       attempt to parse 822.local-part as '822.atom *("." 822.atom)'.  If
  3264.       this fails, or if each 822.atom cannot be parsed as
  3265.       EBNF.atom-encoded then map each character directly.  Otherwise map
  3266.       each "." directly, and each atom as in the previous section.
  3267.  
  3268.       There are places where it is needed to convert between
  3269.       PrintableString or IA5Text (X.400), and 822.word (RFC 822).  word
  3270.       may be encoded as 822.atom (which has a restricted character set)
  3271.       or as 822.quoted-string, which can handle all ASCII characters.
  3272.       If 822.quoted-string is used, clearly the mappings for
  3273.       PrintableString defined in Chapter 3 provide a straightforward
  3274.       mapping.  However, some RFC 822 based networks cannot handle the
  3275.       822.quoted-string format in all cases.  This Appendix is for use
  3276.       in these cases.  The major requirement for this mapping is the
  3277.       UNIX world, but it may well be needed in other places.
  3278.  
  3279.       These mappings are somewhat artificial, and their usage is
  3280.       discouraged, except in cases where there is no alternative.
  3281.  
  3282.  
  3283.  
  3284.  
  3285.  
  3286.  
  3287.  
  3288.  
  3289.  
  3290.  
  3291.  
  3292.  
  3293.  
  3294.  
  3295.  
  3296.  
  3297.  
  3298.  
  3299.  
  3300.  
  3301.  
  3302.  
  3303.  
  3304.  
  3305. Kille                                                          [Page 58]
  3306.  
  3307.  
  3308.  
  3309. RFC 987                                                        June 1986
  3310. Mapping between X.400 and RFC 822
  3311.  
  3312.  
  3313. Appendix B -- Mappings Specific to JNT Mail
  3314.  
  3315.    This Appendix is specific to the JNT Mail Protocol.  It describes
  3316.    specific changes in the context of this protocol.  Addressing is not
  3317.    discussed here, as it is covered in Appendix A.
  3318.  
  3319.    1.  Introduction
  3320.  
  3321.       There are four aspects of a gateway which are JNT Mail Specific,
  3322.       in addition to those relating to addressing.  These are each given
  3323.       a section of this appendix.
  3324.  
  3325.    2.  Acknowledge-To:
  3326.  
  3327.       This field has no direct functional equivalent in X.400.  However,
  3328.       it can be supported to an extent, and can be used to improve X.400
  3329.       support.
  3330.  
  3331.       When going from JNT Mail to X.400, the User Report Request bits of
  3332.       each P1.RecipientInfo.perRecipientFlag should be set to confirmed.
  3333.       If there is more that one address in the Acknowledge-To: field, or
  3334.       if the one address is not equivalent to the 822-P1 return address,
  3335.       then:
  3336.  
  3337.          a.   Acknowledgement(s) should be generated by the gateway.
  3338.               The text of these acknowledgements should indicate that
  3339.               they are generated by the gateway.
  3340.  
  3341.          b.   The Acknowledge-To: field should also be passed in the
  3342.               first P2.BodyPart.
  3343.  
  3344.       When going from X.400 to JNT Mail, in cases where
  3345.       P1.RecipientInfo.perRecipientFlag has the user bits set to
  3346.       confirmed the copy of the message to that recipient should have an
  3347.       Acknowledge-To: field containing the P.UMPDUEnvelope.originator.
  3348.       No attempt should be made to map Receipt notification requests
  3349.       onto Acknowledge-To:.  This is because no association can be
  3350.       guaranteed between P2 and P1 level addressing information.
  3351.  
  3352.    3.  Trace
  3353.  
  3354.       JNT Mail trace uses the Via: syntax.  When going from JNT Mail to
  3355.       X.400, the following mapping onto P1.TraceInformation is used.
  3356.  
  3357.          P1.DomainSuppliedInfo.action is set to relayed.
  3358.  
  3359.          P1.DomainSuppliedInfo.arrival is set to the date-time component
  3360.  
  3361.  
  3362. Kille                                                          [Page 59]
  3363.  
  3364.  
  3365.  
  3366. RFC 987                                                        June 1986
  3367. Mapping between X.400 and RFC 822
  3368.  
  3369.  
  3370.          of the Via: field.  P1.DomainSuppliedInfo.previous has
  3371.          P1.CountryName as a null string, and
  3372.          P1.AdministrationDomainName as the domain specified in the Via:
  3373.          field.
  3374.          P1.TraceInformation.GlobalDomainIdentifier has P1.CountryName
  3375.          as a null string, and P1.AdministrationDomainName as any
  3376.          commented information in the Via: field.  For example:
  3377.  
  3378.             Via: UK.AC.Edinburgh ; 17 Jun 85 9:15:29 BST (EMAS V7)
  3379.  
  3380.             maps to -
  3381.  
  3382.             P1.GlobalDomainIdentifier
  3383.                CountryName                  = ""
  3384.                AdministrationDomainName     = "(EMAS V7)"
  3385.             P1.DomainSuppliedInfo
  3386.                arrival                      = 17 Jun 85 9:15:29 BST
  3387.                action                       = relayed
  3388.                previous
  3389.                   CountryName               = ""
  3390.                   AdministrationDomainName  = "UK.AC.Edinburgh"
  3391.  
  3392.    4.  Timezone specification
  3393.  
  3394.       The extended syntax of zone defined in the JNT Mail Protocol
  3395.       should be used in the mapping of UTCTime defined in chapter 3.
  3396.  
  3397.    5.  Lack of separate 822-P1 originator specification
  3398.  
  3399.       In JNT Mail the default mapping of the P1.MPDUEnvelope.originator
  3400.       is to the Sender: field.  This can cause a problem if the mapping
  3401.       of P2.Heading has already generated a Sender: field.  To overcome
  3402.       this, new extended JNT Mail field is defined.  This is chosen to
  3403.       align with the JNT recommendation for interworking with full
  3404.       RFC 822 systems [Kille84b].
  3405.  
  3406.          original-sender     = "Original-Sender" ":" mailbox
  3407.  
  3408.       If an IPM has no P2.heading.authorisingUsers component and
  3409.       P2.Heading.originator.ORName is different from
  3410.       P1.UMPDUEnvelope.originator, map P1.MPDUEnvelope.originator onto
  3411.       the Sender: field.
  3412.  
  3413.       If an IPM has a P2.heading.authorisingUsers component, and
  3414.       P2.Heading.originator.ORName is different from
  3415.       P1.UMPDUEnvelope.originator, P1.MPDUEnvelpoe.originator should be
  3416.  
  3417.  
  3418.  
  3419. Kille                                                          [Page 60]
  3420.  
  3421.  
  3422.  
  3423. RFC 987                                                        June 1986
  3424. Mapping between X.400 and RFC 822
  3425.  
  3426.  
  3427.       mapped onto the Sender: field, and P2.Heading.originator mapped
  3428.       onto the Original-Sender: field.
  3429.  
  3430.       In other cases the P1.MPDUEnvelope.Originator is already correctly
  3431.       represented.
  3432.  
  3433.       Note that in some pathological cases, this mapping is
  3434.       asymmetrical.
  3435.  
  3436.  
  3437.  
  3438.  
  3439.  
  3440.  
  3441.  
  3442.  
  3443.  
  3444.  
  3445.  
  3446.  
  3447.  
  3448.  
  3449.  
  3450.  
  3451.  
  3452.  
  3453.  
  3454.  
  3455.  
  3456.  
  3457.  
  3458.  
  3459.  
  3460.  
  3461.  
  3462.  
  3463.  
  3464.  
  3465.  
  3466.  
  3467.  
  3468.  
  3469.  
  3470.  
  3471.  
  3472.  
  3473.  
  3474.  
  3475.  
  3476. Kille                                                          [Page 61]
  3477.  
  3478.  
  3479.  
  3480. RFC 987                                                        June 1986
  3481. Mapping between X.400 and RFC 822
  3482.  
  3483.  
  3484. Appendix C -- Mappings Specific to Internet Mail
  3485.  
  3486.    The Simple Mail Transfer Protocol [Postel82a] is used in the
  3487.    ARPA-Internet, and in any network following the US DoD standards for
  3488.    internetwork protocols.  This appendix is specific to those hosts
  3489.    which use SMTP to exchange mail.
  3490.  
  3491.    1.   Mapping between O/R names and SMTP addresses
  3492.  
  3493.       The mappings of Chapter 4 are to be used.
  3494.  
  3495.    2.   Use of the ARPA Domain System
  3496.  
  3497.       Whenever possible, domain-qualified addresses should be be used to
  3498.       specify encoded O/R names.  These domain encodings naturally
  3499.       should be independent of any routing information.
  3500.  
  3501.    3.   Identification of gateways
  3502.  
  3503.       The ARPA-Internet Network Information Center (NIC) will maintain a
  3504.       list of registered X.400 gateways in the ARPA Internet.
  3505.  
  3506.  
  3507.  
  3508.  
  3509.  
  3510.  
  3511.  
  3512.  
  3513.  
  3514.  
  3515.  
  3516.  
  3517.  
  3518.  
  3519.  
  3520.  
  3521.  
  3522.  
  3523.  
  3524.  
  3525.  
  3526.  
  3527.  
  3528.  
  3529.  
  3530.  
  3531.  
  3532.  
  3533. Kille                                                          [Page 62]
  3534.  
  3535.  
  3536.  
  3537. RFC 987                                                        June 1986
  3538. Mapping between X.400 and RFC 822
  3539.  
  3540.  
  3541. Appendix D -- Mappings Specific to Phonenet Mail
  3542.  
  3543.    There are currently no mappings specific to Phonenet Mail.
  3544.  
  3545.  
  3546.  
  3547.  
  3548.  
  3549.  
  3550.  
  3551.  
  3552.  
  3553.  
  3554.  
  3555.  
  3556.  
  3557.  
  3558.  
  3559.  
  3560.  
  3561.  
  3562.  
  3563.  
  3564.  
  3565.  
  3566.  
  3567.  
  3568.  
  3569.  
  3570.  
  3571.  
  3572.  
  3573.  
  3574.  
  3575.  
  3576.  
  3577.  
  3578.  
  3579.  
  3580.  
  3581.  
  3582.  
  3583.  
  3584.  
  3585.  
  3586.  
  3587.  
  3588.  
  3589.  
  3590. Kille                                                          [Page 63]
  3591.  
  3592.  
  3593.  
  3594. RFC 987                                                        June 1986
  3595. Mapping between X.400 and RFC 822
  3596.  
  3597.  
  3598. Appendix E -- Mappings Specific to UUCP Mail
  3599.  
  3600.    Gatewaying of UUCP and X.400 is handled by first gatewaying the UUCP
  3601.    address into RFC 822 syntax (using RFC 976) [Horton86a] and then
  3602.    gatewaying the resulting RFC 822 address into X.400.  For example, an
  3603.    X.400 address
  3604.  
  3605.       Country         US
  3606.       Organization    Xerox
  3607.       Personal Name   John Smith
  3608.  
  3609.    might be expressed from UUCP as
  3610.  
  3611.       inthop!gate!gatehost.COM!/C=US/O=Xerox/PN=John.Smith/
  3612.  
  3613.    (assuming gate is a UUCP-ARPA gateway and gatehost.COM is an
  3614.    ARPA-X.400 gateway) or
  3615.  
  3616.       inthop!gate!Xerox.COM!John.Smith
  3617.  
  3618.    (assuming that Xerox.COM and /C=US/O=Xerox/ are equivalent.)
  3619.  
  3620.    In the other direction, a UUCP address Smith@ATT.COM, integrated into
  3621.    822, would be handled as any other 822 address.  A non-integrated
  3622.    address such as inthop!dest!user might be handled thought a pair of
  3623.    gateways:
  3624.  
  3625.       Country         US
  3626.       ADMD            ATT
  3627.       PRMD            ARPA
  3628.       Organization    GateOrg
  3629.       RFC-822         inthop!dest!user@gatehost.COM
  3630.  
  3631.    or through a single X.400 to UUCP gateway:
  3632.  
  3633.       Country         US
  3634.       ADMD            ATT
  3635.       PRMD            UUCP
  3636.       Organization    GateOrg
  3637.       UUCP            inthop!dest!user
  3638.  
  3639.  
  3640.  
  3641.  
  3642.  
  3643.  
  3644.  
  3645.  
  3646.  
  3647. Kille                                                          [Page 64]
  3648.  
  3649.  
  3650.  
  3651. RFC 987                                                        June 1986
  3652. Mapping between X.400 and RFC 822
  3653.  
  3654.  
  3655. Appendix F -- Format of Address Mapping Tables
  3656.  
  3657.    There is a need to specify the association between the domain and
  3658.    X.400 namespaces described in 4.2.1.  This is defined as a table
  3659.    syntax, but the syntax is defined in a manner which makes it suitable
  3660.    for use with domain nameservers (such as the DARPA Domain nameservers
  3661.    or the UK NRS).  The symmetry of the mapping is not clear, so a
  3662.    separate table is specified for each direction.  For domain -> X.400:
  3663.  
  3664.       domain-syntax "#" dmn-orname "#"
  3665.  
  3666.       For example:
  3667.  
  3668.       AC.UK#PRMD$DES.ADMD$BT.C$UK#
  3669.       XEROX.COM#O$Xerox.ADMD$ATT.C$US#
  3670.  
  3671.    For X.400 -> domain:
  3672.  
  3673.       dmn-orname "#" domain-syntax "#"
  3674.  
  3675.    EBNF.domain-syntax will be interpreted according to RFC 920.
  3676.    EBNF.dmn-orname will have components ordered as defined in section
  3677.    4.2.1, and with the most significant component on the RHS.
  3678.  
  3679.  
  3680.  
  3681.  
  3682.  
  3683.  
  3684.  
  3685.  
  3686.  
  3687.  
  3688.  
  3689.  
  3690.  
  3691.  
  3692.  
  3693.  
  3694.  
  3695.  
  3696.  
  3697.  
  3698.  
  3699.  
  3700.  
  3701.  
  3702.  
  3703.  
  3704. Kille                                                          [Page 65]
  3705.  
  3706.  
  3707.  
  3708. RFC 987                                                        June 1986
  3709. Mapping between X.400 and RFC 822
  3710.  
  3711.  
  3712. References
  3713.  
  3714.    Bonacker85a.
  3715.  
  3716.       K.H. Bonacker, U. Pankoke-Babatz, and H. Santo, "EAN - Conformity
  3717.       to X.400 and DFN-Pflichtenheft," GMD (Gesellschaft fur Mathematik
  3718.       und Datenverarbeitung) report, June 1985.
  3719.  
  3720.    CCITT84a.
  3721.  
  3722.       CCITT SG 5/VII, "Recommendations X.400," Message Handling Systems:
  3723.       System Model - Service Elements, October 1984.
  3724.  
  3725.    CCITT84b.
  3726.  
  3727.       CCITT SG 5/VII, "Recommendations X.411," Message Handling Systems:
  3728.       Message Transfer Layer, October 1984.
  3729.  
  3730.    CCITT84c.
  3731.  
  3732.       CCITT SG 5/VII, "Recommendations X.420," Message Handling Systems:
  3733.       Interpersonal Messaging User Agent Layer, October 1984.
  3734.  
  3735.    CCITT84d.
  3736.  
  3737.       CCITT SG 5/VII, "Recommendations X.409," Message Handling Systems:
  3738.       Presentation Transfer Syntax and Notation, October 1984.
  3739.  
  3740.    CEN/CENELEC/85a.
  3741.  
  3742.       CEN/CENELEC/Information Technology/Working Group on Private
  3743.       Message Handling Systems, "FUNCTIONAL STANDARD A/3222,"
  3744.       CEN/CLC/IT/WG/PMHS N 17, October 1985.
  3745.  
  3746.    Crocker82a.
  3747.  
  3748.       D.H. Crocker, "Standard of the Format of ARPA Internet Text
  3749.       Messages," RFC 822, August 1982.
  3750.  
  3751.    Horton85a.
  3752.  
  3753.       M.R. Horton, "Draft Standard for ARPA/MHS Addressing Gateways,"
  3754.       AT&T Bell Laboratories, October 1985.
  3755.  
  3756.  
  3757.  
  3758.  
  3759.  
  3760.  
  3761. Kille                                                          [Page 66]
  3762.  
  3763.  
  3764.  
  3765. RFC 987                                                        June 1986
  3766. Mapping between X.400 and RFC 822
  3767.  
  3768.  
  3769.    Horton86a.
  3770.  
  3771.       M.R. Horton, "UUCP Mail Interchange Format Standard", RFC 976,
  3772.       February 1986.
  3773.  
  3774.    ICL84a.
  3775.  
  3776.       ICL, "Comparison of service elements of Grey Book Mail and X.400,"
  3777.       Mailgroup Note 18: Extract from unpublished report for ITSU
  3778.       (Information Technology Standards Unit), July 1984.
  3779.  
  3780.    Kille84a.
  3781.  
  3782.       S.E. Kille, (editor), JNT Mail Protocol (revision 1.0), Joint
  3783.       Network Team, Rutherford Appleton Laboratory, March 1984.
  3784.  
  3785.    Kille84b.
  3786.  
  3787.       S.E. Kille, "Gatewaying between RFC 822 and JNT Mail," JNT
  3788.       Mailgroup Note 15, May 1984.
  3789.  
  3790.    Kille86a.
  3791.  
  3792.       S.E. Kille, "O/R Names in the UK Academic Community," UK Working
  3793.       Document, March 1986.
  3794.  
  3795.    Larmouth83a.
  3796.  
  3797.       J. Larmouth, "JNT Name Registration Technical Guide," Salford
  3798.       University Computer Centre, April 1983.
  3799.  
  3800.    Neufeld85a.
  3801.  
  3802.       G. Neufeld, J. Demco, B. Hilpert, and R. Sample, "EAN: an X.400
  3803.       message system," in Second International Symposium on Computer
  3804.       Message Systems, Washington, pp. 1-13, North Holland,
  3805.       September 1985.
  3806.  
  3807.    Postel82a.
  3808.  
  3809.       J. Postel, "Simple Mail Transfer Protocol," RFC 821, August 1982.
  3810.  
  3811.    Postel84a.
  3812.  
  3813.       J. Postel and J. Reynolds, "Domain Requirements," RFC 920,
  3814.       October 1984.
  3815.  
  3816.  
  3817.  
  3818. Kille                                                          [Page 67]
  3819.  
  3820.  
  3821.  
  3822. RFC 987                                                        June 1986
  3823. Mapping between X.400 and RFC 822
  3824.  
  3825.  
  3826.    Rose85a.
  3827.  
  3828.       M.T. Rose, "Mapping Service Elements between ARPA and MHS," Draft
  3829.       proposal, October 1985.
  3830.  
  3831.    Rose85b.
  3832.  
  3833.       M.T. Rose and E.A. Stefferud, "Proposed Standard for Message
  3834.       Encapsulation," RFC 934, January 1985.
  3835.  
  3836.  
  3837.  
  3838.  
  3839.  
  3840.  
  3841.  
  3842.  
  3843.  
  3844.  
  3845.  
  3846.  
  3847.  
  3848.  
  3849.  
  3850.  
  3851.  
  3852.  
  3853.  
  3854.  
  3855.  
  3856.  
  3857.  
  3858.  
  3859.  
  3860.  
  3861.  
  3862.  
  3863.  
  3864.  
  3865.  
  3866.  
  3867.  
  3868.  
  3869.  
  3870.  
  3871.  
  3872.  
  3873.  
  3874.  
  3875. Kille                                                          [Page 68]
  3876.  
  3877.  
  3878.  
  3879. RFC 987                                                        June 1986
  3880. Mapping between X.400 and RFC 822
  3881.  
  3882.  
  3883. Notes:
  3884.  
  3885.    <0>  UNIX is a trademark of Bell Laboratories.
  3886.  
  3887.    <1>  The term gateway is used to describe a component performing the
  3888.         protocol mappings between RFC 822 and X.400.  This is standard
  3889.         usage amongst mail implementors, but should be noted carefully
  3890.         by transport and network service implementors.  (Sometime called
  3891.         a "mail relay".)
  3892.  
  3893.    <2>  If the remote protocol is JNT Mail, a notification may also be
  3894.         sent by the recipient UA.
  3895.  
  3896.    <3>  The asymmetry occurs where an ASCII string contains the sequence
  3897.         EBNF.ps-encoded-char.  This would be mapped directly to
  3898.         PrintableString, but the reverse mapping would be to the value
  3899.         implied by the sequence.
  3900.  
  3901.    <4>  It might be suggested that for reasons of elegance,
  3902.         EBNF.ps-delim (left parenthesis) is encoded as
  3903.         EBNF.ps-encoded-char. This is not done, as it it would never be
  3904.         possible to represent a PrintableString containing the character
  3905.         "(" in ASCII.  This is because an "(" in ASCII would be mapped
  3906.         to the encoding in PrintableString.
  3907.  
  3908.    <5>  In practice, a gateway will need to parse various illegal
  3909.         variants on 822.date-time.  In cases where 822.date-time cannot
  3910.         be parsed, it is recommended that the derived UTCTime is set to
  3911.         the value at the time of translation.
  3912.  
  3913.    <6>  P2.ORname is defined as P1.ORName.
  3914.  
  3915.    <7>  This recommendation may change in the light of CCITT or
  3916.         CEN/CENELEC guidelines on the use of initials.
  3917.  
  3918.    <8>  It would be possible to use a ForwardedIPMessage for these
  3919.         fields, but the semantics are (arguably) slightly different, and
  3920.         it is probably not worth the effort.
  3921.  
  3922.    <9>  Although this violates chapter 1, part 4, principles 2 and 3, it
  3923.         is suggested that this is justified by principle 1.
  3924.  
  3925.  
  3926.  
  3927.  
  3928.  
  3929.  
  3930.  
  3931.  
  3932. Kille                                                          [Page 69]
  3933.